SInce rebuilding our VST3 plugin with JUCE 7.0.2, JUCE_ASSERT_MESSAGE_THREAD triggers in getNumSingleDirectionChannelsFor() in juce_VST3PluginFormat.cpp when our plugin is scanned by AudioPluginHost from its plugin list dialog. We don’t get this issue when the plugin is loaded directly into a graph so I’m guessing it’s just the folder scanning process that’s on a pool thread in AudioPluginHost that’s causing the problem. Is there a fix on the way for this, or is there something we should be doing differently in our plugin to work safely here? (Though there’s none of our code in the call stack when the assert is triggered so I’m not sure what we could do differently.)
I think the issue is on the host side. The AudioPluginHost opens and queries plugins on a background thread when it’s scanning in-process, but some of the plugin functions are only supposed to be called on the UI thread. Changing this behaviour is not straight-forward, and could end up blocking the main thread for extended periods, freezing the host UI.
I’d recommend using the out-of-process scanner instead. In this mode, the scanner correctly opens plug-ins on the main thread.
Ah, I’d missed that little drop down. (Or maybe I had seen it a while ago and decided to leave it alone because I didn’t know what it was for .)
Thanks for the quick reply.
Is there a particular reason out-of-process scanning isn’t the default choice?
In-process was the only choice previously. We kept it as the default so that users wouldn’t see new (potentially unexpected) behaviour unless they opted in. This was particularly important at first, as the new mode was more likely to contain bugs than the old, established mode. In-process mode is also easier to debug in the case of loading-related crashes.