Multibus and Speaker Arrangement in VST3: something needs to be done

Audio Plugins
1

Hi

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…

Cheers

Fred

2

I know @fabian had some thoughts on this - I’ll wait until he gets a chance to reply, as the subtleties of this stuff are a bit beyond the rest of us!

2 Likes
3

Sorry for the late reply. In deed there was a bug in the VST3 hosting code which ignored any buses with zero channels. I’ve fixed this in commit 1259cdf which is now on develop. Thanks for reporting!

That’s true although I do believe the current approach in JUCE provides more flexibility* for developers. If you want to follow the VST3 sdk’s advice then you can set the bus arrangement to something that makes sense (for example the same layout as the track that the plug-in is loaded on) immediately after loading a plug-in. Having JUCE guess which arrangement you want wouldn’t be the right approach, I think. Also, there are non-JUCE hosts that do use the initial bus arrangement when loaded (like Bidule for example).

Let me know if the above commit fixes the issue for you.

2 Likes
4

Thanks a lot Fabian!
It works now.
Btw I added a pull request to develop branch for the swapping of Side / SurroundRear Speaker Types in the VST3/Juce::AudioChannelSet::ChannelType wrapping.
https://github.com/WeAreROLI/JUCE/pull/404

Cheers

Fred