VST2 SpeakerArrangement / VST3 BusArrangements host calling sequence compliancy considerations

I’m using the plug-in hosting in my application for VST2 and VST3 plugins and I’m facing plug-ins support issues in terms of IO setup / capabilities detection from some manufacturers.
I contacted one of the manufacturer to discuss the issue with his VST2 and VST3 plug-ins and had to admit that he is totally compliant with the specifications of the calling sequences of both Steinberg SDKs. But I’m afraid JUCE hosting is not…

  • For VST2, the SDK describes the SpeakerArrangement negociation as follows :

  • setSpeakerArrangement(…)
  • if successful: end of story
  • if not: call getSpeakerArrangement(…) and call again setSpeakerArrangement(…) with the retrieved layout.

What JUCE does is:

  • getSpeakerArrangement(…) (pluginHasDefaultChannelLayouts call)

  • if unsuccessful getPinProperties() (still in pluginHasDefaultChannelLayouts call)

  • if still unsuccessful in retrieving a speaker arrangement, finally call setSpeakerArrangement(.) based on the cannonical audioChannelSet for the number of IO.

  • getSpeakerArrangement(…)

  • if unsuccessful, assumes empty IO speaker arrangement and consider that each channel is a mono bus (which is wrong)
    Now think of a one bus 8 channels plug-in which return false for getSpeakerArrangement(…) (e.g. a plug-in which can deal with any layout as long in respect to the max number of I/O), this will end up with a 8 mono bus AudioProcessor, and no way to setup the plug-in to do multichannel. And yet, the plug-in follows the SDK specification.

  • For VST3, the SDK describes the BusArrangement negociation as follows :

so basically: setBusArrangement() call
then : getBusArrangement() call

What JUCE does is to start calling getBusArrangement() for each bus to retrieve a layout.
Now for example, if a single bus plug-in does not return OK on this call (e.g. considering that since no IO setup has been specified yet, there is nothing to return), you unfortunately end up with a zero input / zero output AudioProcessor. Again in this case, such plug-in can be still considerered compliant with the SDK specification.

Would it be possible to have this compliancy problem fixed?
On such a issue, I’m not in position to tell a manufacturer to change its code to accomodate ours as it does not do anything against the rules, and have its plug-ins running fine with Steinberg hosts.


Best Regards

Fred / Merging Technologies

1 Like


Unfortunately Fabian is the only human who fully understands bus layout handling, and he’s away for a few weeks…

Fair enough, I will be away for a couple weeks too so I’ll remind him early January 2018.




Any news?

I think he’s back next week :slight_smile:

1 Like

Great, thanks for the update.

Any news?

Yes, we’ve been aware of this compliancy problem for a long time now. Unfortunately, plug-ins created with an old JUCE version would crash if you called setSpeakerArrangement before getSpeakerArrangement - therefore we needed to add a workaround to the hosting code. See juce_VSTPluginFormat.cpp:L2074 for some more comments on this problem.

Maybe it’s about time though to remove the workaround.


Thanks for the clarification, Fabian. So we can simply comment out the work-around to get it compliant, right?

Yes, the if branch on line 2080 should always be taken.

Perfect, thanks!

Thanks for the update.
What about VST3 BusArrangement negotiation compliancy?