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

David García Garzón dgarcia at iua.upf.edu
Wed Apr 15 10:16:39 PDT 2009


On Wednesday 15 April 2009 17:42:25 Andreas Beisler wrote:
> 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.

Ok, i think i can guess the point. As i told you I sent a wrong version to the 
mailing list that, among other bugs, opened the window as a new top level 
window like this[1]. However the code on the svn does create a child window 
but just within the given one [2]. Is that what you say? I mean, the 
child 'window' is not a top level, but something like having a child QWidget 
of a dialog. When i tried to make the given HWND a QWidget, i also got the 
crash on close you say. I guessed that the host and qt window handling was 
colliding, so to avoid problems i introduced the child.

Don't rely on the code sent to the ML. Take a look at the differences with the 
svn one.

Anyway, I wish you find how to use directly the given HWND and still 
well-behaving with the host. The problem i see by using the child is the 
extra margins, for instance.

[1]http://clam-project.org/wiki/Image:Vst-qttoplevel.png
[2]http://clam-project.org/wiki/Image:Vst-qt.png


> >> 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.

Well it seems not to complaint ;-)

> >> 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-de
> >>>>ve l






More information about the clam-devel mailing list