VST2 SpeakerArrangement / VST3 BusArrangements host calling sequence compliancy considerations

Audio Plugins
1

Hello
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 :

    vst3_processor_call_sequence
    vst3_processor_call_sequence.jpg723×1263 148 KB

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.

Thanks

Best Regards

Fred / Merging Technologies

2 Likes
Multibus and Speaker Arrangement in VST3: something needs to be done
Issues with sidechain channel configuration in VST3 / Cubase
2

+1

3

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

4

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

Fred

5

Up

Fred

6

Any news?

7

I think he’s back next week :slight_smile:

1 Like
8

Great, thanks for the update.

9

Any news?

10

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.

2 Likes
11

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

12

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

13

Perfect, thanks!

14

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