(Accidentally posted in another topic. Here’s the new post.)
I am wondering about the thread safety of VSTPluginInstance. I am attempting to use several instances of VSTPluginInstance running on different threads and I sometimes get a jassert in the VSTPluginInstance destructor. Looking at the juce_VSTPluginFormat source code, it seems that the use of the variable “insideVSTCallback” is not thread-safe since it is a static int – meaning that all threads will be touching the same variable.
Except for the occasional jassert, using several instances of VSTPluginInstance seems to work. For what I’m working on, it’s not absolutely essential that I use multiple threads, but I would like to use all the available cores if possible.
You absolutely must call all of a plugin’s methods from the main event thread (apart from its audio processing methods, obviously). Even if the juce class managed to cope with multithreaded access (and it’s not designed to), a lot of plugins will go horribly wrong if you start trying to make them multithreaded.
Let me explain my scenario in a little more detail. I’m trying to use plugins in a thread pool, where each thread pool job does the following.
- Creates a vst plugin instance.
- Sets the plugin’s program chunk
- Uses the plugin’s processBlock call to process data in an “offline bounce” mode.
- Destroys the plugin instance.
So each plugin instance is only used by a single thread and the plugin’s editor is not displayed.
It looks like I can use a CriticalSection for actions 1, 2, and 4. It would be nice if it was not necessary to use the CriticalSection since each plugin is being accessed by a separate thread and there is not really any shared resource in use.
Even if you’re not opening their GUIs, I still wouldn’t trust all plugins to work correctly unless you do 1, 2 and 4 with the message thread.