[Clam-devel] Re: VST plugins with qt interface!

Andreas Beisler ebfx at smartelectronix.com
Wed Apr 15 08:42:25 PDT 2009

David García Garzón wrote:
> On Wednesday 15 April 2009 13:09:06 Andreas Beisler wrote:
>> I succeeded reparenting the system window that we get from the host as a
>> QWidget. It just worked the straight-forward way by just compiling with
>> static runtime (/MT).
>> When I tested reparenting the system window with dynamic runtime (/MD)
>> nothing happened.
> That's interesting. Anyway, do we get any benefits by using the sys window we 
> get? Does it solves any of the many problems (scaling, events...)? Are you 
> using the version from the svn which fixed some bugs?
> Because the options I guess you are not using mingw but visual, aren't you? 
> Nice to know that it also works in visual.

We don't get a benefit per se. It's just not very nice to not use the 
HWND that we get from the host. You know, the common usage is that we 
draw our GUI directly into the given window and don't open another 
window ourselves.

The issues you were mentioning I am not considering yet, since I am 
still at a stage where I just want to get something stable that doesn't 
crash on close.

I use an own simple test case in MSVC, not the svn code from you. I just 
briefly looked at your code, but I didn't run it.

>> There are still some open issues tho. I.e. the test if qApp exists is
>> not really working for a DLL. It basically creates a new QApplication
>> every time you instantiate a plugin.
> That's more or less the intent. I mean, the qapp is for each plugin instance. 
> As plugin we don't know whether the host is a Qt app or whether other plugins 
> also use Qt. We need a qapp to have an event loop and to initialize qt. Maybe 
> there is a cheaper way to do that than creating a QApp, but i dunno.

I've been told that there should only be one single qApp present in a 
process. Not sure if that is true or not. So, I don't think we should 
create a new QApplication each time we instantiate the plugin.


>> The good thing is: I got someone from trolltech who will spend his next
>> 'creative friday' on the open issues to open up qt to the vst world.
> Having a troll involved in that would be fantastic! It was hard for me 
> figuring out the inner working of Qt in windows, an insider could do a lot 
> better and often could be better to adapt Qt than to hack around.
>> I'll keep you updated.
> Yes, please. Thanks for the research.
> David.
>> David García Garzón wrote:
>>> Yes, also when i did weird things happened. I deduced that you cannot
>>> turn that window a QWidget because then Qt overwrites the callbacks of
>>> the host for that window. So i created a child in the win32 way and then
>>> use it for the QWidget.
>>> Notice that i fixed a couple of bugs. An updated version is in:
>>> http://clam-
>>> project.org/clam/trunk/CLAM/examples/PluginExamples/VstPluginExample/
>>> And the interesting (and clam independent bits, regardless the name), are
>>> in QClamVstEditor.*xx
>>> This is very experimental stuff but I cannot dedicate time on this for
>>> some time, so if you manage to enhance the behaviour, i would be very
>>> glad if you can report it back.
>>> David.
>>> A Tuesday 14 April 2009 20:02:05, Andreas Beisler va escriure:
>>>> Hi David,
>>>> I just had a quick look at the spike solution for creating vst plugins
>>>> with a qt gui.
>>>> In QADelayEditor-0001.cpp I saw that you took the window handle that the
>>>> vst host passes to you and then you created a child window for that,
>>>> which is a QWidget.
>>>> Is there any way to re-use the window handle from the host directly?
>>>> I did some preliminary tests, but it failed. It just worked by creating
>>>> a new child window.
>>>> Best regards,
>>>> Andreas
>>>> _______________________________________________
>>>> Clam-devel mailing list
>>>> Clam-devel at llistes.projectes.lafarga.org
>>>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-deve
>>>> l

More information about the clam-devel mailing list