This topic relates somehow to Multibus and Speaker Arrangement
Also to my previous VST2 SpeakerArrangement / VST3 BusArrangements host calling sequence compliancy considerations topic.
Well I see similar problems with all Nugen plugins in VST3 when hosted by Juce VST3PluginFormat.
None of them shows any bus with JUCE VST3 hosting (tested with extras’ AudioPluginHost).
They work fine with Steinberg’s VST3PluginTestHost though. (e.g. VisLM2 in VST3 win64, shows one stereo in, one stereo out).
From what I could see, the problem is that the Juce hosting implementation assumes that a vst3 plugin will report a non empty default IO setup right after Component instance creation (hence before its initialization and VST3 audioprocessor retrieval btw).
In the case of NUGEN VST3 plug-ins, the behaviour is that until the first setBusArrangement, the returned Buses info will show one input bus/ one output bus, both with with 0 channels.
VST3 sdk stipulates that buses info should be retrieved after each call to setBusArrangement (and it follows the the same paradigm as VST2.4) so nothing exotic here. But in the Juce VST3PluginInstance implementation, setBusArrangement() is only followed by a getBusArrangement(), using potentially outdated busesLayout info.
Since the current code filters out 0 channels buses, that leads Juce AudioProcessor to have empty inputBuses and outputBuses, without any chance to ever get populated later, and as a consequence, no chance to make any further relevant getBusArrangement() calls.
If I remove the 0 channels buses filtering, inputBuses and outputBuses won’t be empty this time, but will never be in sync with actual VST3 busInfo you could get by calling getBusInfo.
NugenAudio is not the only plug-in manufacturer affected by this IO layout setup approach (Exponential Audio is another example).
Although a syncBusLayouts() exists in, it doesn’t seem do what it sounds like it should do. And Descriptor filling / pre-initialisation appart, no direct communication with the plug-in occurs to inquiry the current buses setup.
I tried to find a way to fix that to submit a code change, but haven’t managed to get through the complexity of the AudioProcessor BusLayouts setup/negotiation to have something working.
Well, basically, AudioProcessor::BusLayouts class does not offer enough flexibility/accessors to easily allow an I/O buses refresh based on the current state of a VST3 plug-in instance.
So any suggestion is welcome.
Otherwise I guess I’ll have to write my own VST3 hosting code…