I've tried doing this in order to load a plugin and embed its GUI into my content component :
PluginDescription* desc = m_kplist->getType(the_proc_info.m_plugin_id);
AudioPluginInstance* pluginst = vstformat.createInstanceFromDescription(*desc,44100.0,512);
if (pluginst != nullptr)
Logger::writeToLog("Managed to create plugin " + pluginst->getName());
if (pluginst->hasEditor() == true)
AudioProcessorEditor* ed = pluginst->createEditor();
GenericAudioProcessorEditor* ed = new GenericAudioProcessorEditor(pluginst);
m_plugin_instance = pluginst;
Which seems to work at first, but fails slightly unpredictably (that is, almost everytime but not always) if I try running the code again for another plugin. When the failure happens, the call stack shows some Juce timer keeps running and attempts to call into an invalid plugin instance. There appears to be no code of mine in the call stack. Does this have to do with the plugin GUI being added as a child of the content component? Or am I destroying the previous plugin instance in some incorrect way?
If it's about having the plugin GUI as a child component, that's unfortunate as I would really like to not have the plugin GUI as a separate window, which is how for example the Juce plugin hosting demo does it.
I'd appreciate if you could take a look at your code. I did myself try various other things (removing the plugin editor explicitly from the parent component, deleting the GUI editor explicitly before deleting the plugin etc) than what is shown in the code above, but nothing seemed to help this issue.
You can put the hosted gui in a Component. But only one at the time. The plugins need their own native window.
By best advice is to keep this simple and don’t try anything creative as there are lots of plugins out there that make assumptions on how the host handles the plugin window
Hmm well, for example Reaper, FL Studio and Cubase do have their own added GUI elements around the plugin GUI, so it isn't exceptional to have that kind of plugin GUI handling. IMHO that should work with Juce's plugin hosting too.
I wonder if it would help if I add a Juce Component into my content Component that would only have the plugin GUI as a child component...
These hosts might possibly place an independent, borderless window on top of theirs, that moves and resizes with the parent.
I'm just guessing, but remember that I did it this way years ago to cope with issues that arose from adding the GUI as a child component. No idea how I finally got it working, but will have a look into the code.
I assume you are building a plug-in that hosts guest plugins, right?
If however you are building a host, you have more options, as you are in full control of the entire UI.
To remove it, I just delete it, which will remove it from the view hierarchy. Make sure the following things
1. Add/remove the guest-GUI on the message thread only!
2. Delete the GUI only when it's idle, i.e. no render callbacks anymore, no GUI updates (use a lock)
3. Remove your reference to the GUI before you delete it. Make sure it is totally isolated from anything before you delte it (i.e. does not longer receive messages, updates, etc that your parent UI might dispatch to it).
I don't mean just window borders/title bar as those are kind of mandatory to have so that the window with the plugin can be moved, but I mean additional controls/components like in Reaper's plugin windows (the preset dropdown, dry/wet knob etc.) :
Tracktion's plugin container windows don't have stuff like that, right?
My own window that is supposed to have the plugin GUI "embedded" is just a bit more complicated than the above screenshot.
Multiple plugin GUIs within the same window was actually something I was planning to attempt, but I suppose I'll have to skip that at least with Juce's plugin hosting...
Now I cannot exit the application, because this plugin cannot be unloaded.
I took much time to search about deleting editor before deleting the plugin, but seems no forum discusses about it.
Can you give me a idea about this case?
I still have not fully figured out how the plugin GUI editor components should be handled for my use case…Crashes and other problems still happen. It looks like having a plugin GUI as a child component is just not fully supported in Juce.
If for your use case you only need the plugin in a separate window, the Juce example plugin host seems to have a working solution which you could use for inspiration. (It appears you are trying to have a plugin GUI as the content component of a ResizableWindow or such because you are using setContentComponent,right?)
This works perfect as long you have one child VSTPluginWindow opened. When you open the second one, this code fails. You always get HWND of the LAST opened plugin, so unexpected things start to happen. Interesting is, that even if you put each GUI inside its own parent component and then make this component a child of the main window, it still doesn’t work.
I somehow succeeded – I had to find the proper window handle of each plugin, when GUI is displayed plus a bunch of weird code. It is a realy nasty way of doing it. I would really like to see beter solution for this.