19

I would like to use the Qt GUI library as the user interface for a VST plugin. A VST plugin is a DLL on windows. A host application calls various functions on the DLL, including things like openGUI().

I want to know how to use Qt GUI from a DLL; I have done some research to look at the possible options but I'm not completely sure on the limitations.

The main problem is where to create the QApplication object and call exec() on it (which is a function that does not return until the application has quit).

I have looked at the solution given in this post, but after further reading it would appear this solution will not work on Mac OS X, as Cocoa is more restrictive about the particular thread a GUI can run on. It's a bit of a hack really.

I have also seen this solution, but that relies on QMfcApp and QWinWindow which don't appear to be part of the Qt library any more.

Is the only way round this for my DLL to spawn off a new application itself? Presumably I could start one with a call to QProcess and use some shared memory to share between the GUI application and my VST DLL? Has anyone come across this type of problem? Am I going down a bad route with this or is there something I haven't thought of yet?

Update

After further research I have come across the QAbstractEventDispatcher class. I have seen this post which seems to say it's possible to call QApplication::processEvents() from your own (the host of my plugin) event loop instead of calling QApplication::exec(). Has anyone tried doing this?

Community
  • 1
  • 1
oggmonster
  • 4,672
  • 10
  • 51
  • 73
  • I've done it on windows (the first solution with the seperate thread). It was really difficult since we needed to fire up a seperate thread from dllmain somthing that is prohibited. QMfcApp has never been part of Qt but rather a so called "solution". You find it here http://qt.gitorious.org/qt-solutions/qt-solutions/trees/master/qtwinmigrate. Good luck! – David Feurle Oct 10 '12 at 14:28

3 Answers3

7

It seems like your actual problem is using Qt for a VST plugin on mac, since it was reported to work on Windows - see here (full source tree) and here.

There's a successful report of using Qt for VST plugins on mac in the Qt forums, but on the other hand there's an open bug on the same issue.

I know it doesn't answer your question, but I would suggest going with other UI libraries which are better suited for VST plugins, such as JUCE and WDL.

kshahar
  • 10,423
  • 9
  • 49
  • 73
  • I'm wondering which other library, perhaps the two you're mentioning, actually addresses this problem. I'm currently investigating which cross-platform gui library to use for a similar type of plugin. If somebody has a link where the feasability of using a particular library is talked about, I'd love to hear about it. – John Nov 15 '14 at 21:45
3

Are you going down a bad route with this? Not necessarily, if you are developing a free VST plugin; or are a successful commercial plugin developer. However, as much as I like Qt for general software development, it is not especially well suited to VST development. Its licensing is such that you can't statically link a DLL with its libraries for commercial use, unless you pay for it; and it is quite expensive. When they made it LGPL, it made it so you can put all your dependencies, which easily runs into over a dozen DLL's, for stand-alone, commercial programs in a target program or DLL directory, and it will run and you can sell it commercially; without buying a license.

VST users are used to moving DLL's around willy-nilly so as to move effects around; and they can't have just one to move around under LGPL. Littering directories with lots of extra DLL's to scan makes the scanning process slower. Having lots of dependencies in the folder with your VST plugin will not work very well for commercial plugins the way it will for other commercial plugins; because you can't produce a plugin in a single DLL and statically link it with the Qt libraries without paying a lot for Qt, or making it GPL or some such.

Edit: One argument against it was that Qt does string compares for its signals and slots. The new way of doing signals and slots, using the new connect overloads, does NOT rely on strings.

At a local recording studio, in a Waves plugins installation, I noticed that in the {Waves Install Directory}/Application directory, there are WavesQtLibs folders that have the Qt libraries. It appears that they are using Qt for their applications, but if they are using them for their plugins themselves, they are either statically linking, or not using them. As Waves supports their applications and plugins for multiple platforms, I can see how Qt would be attractive to them. They could afford Qt licenses to develop with, presumably. It appears they are using Qt with DLLs for their applications, which would make it easier to port between operating systems. I don't know if they have a required notice for LGPL use or not. I don't know if they are using Qt statically-linked for their plugins themselves, if they are using the JUCE framework (which, although a bit expensive, is also not gouging its limited user-base on price), or something else.

CodeLurker
  • 1,248
  • 13
  • 22
2

From VST DLL exec the Qt process and then use IPC to share memory between them (or use message passing, etc).

Klathzazt
  • 2,415
  • 19
  • 27