When running the AudioPluginHost example and scanning for VSTs I get
JUCE Assertion failure in juce_VST3PluginFormat.cpp:301 which seems to imply that this function should be called on the message thread but the stack strace show it spawning from a juce::ThreadPool Is something wrong in this example?
interesting. it only seems to cause the assertion failure whenever I run it “in-process”
Sort of - the VST3 spec says that plugins should only be created on the main thread, but creating a plugin can be time-consuming. The in-process plugin scanner runs on a background thread, so that creating and destroying plugin instances doesn’t block the main thread, which may cause the app to become unresponsive. Blocking the main thread is a pretty big problem: the unresponsiveness could easily prevent the user from cancelling the ongoing scan!
For an in-process scanner, we have to pick the lesser of the two evils: either disobeying the VST3 spec, or blocking the main thread and potentially hanging the application.
The out-of-process scanning approach is the best way to work around these problems. The sub-process can load plugins on its main thread without blocking the main thread of the original application. The out-of-process scanner is also more resilient to plugin crashes, as a crash will only terminate the scanner process instead of the original application.
makes sense. Can the out-of-process method work for a VST loading VSTs? I would imagine you can use the same commandline initialise approach so you’d either have to do a juce::ChildProcess::start type of thing with a separate executable and communicate there or take the In-process method
I don’t see why not, it’s just a bit more complicated because you need a separate ‘scanner’ executable that you can invoke from the plugin.
right right. I’ll look into it once I get the standalone version up and running! Will post here if I come up with a clean method