Multiple channel configurations in VST

I just discovered that the vst wrapper uses JucePlugin_MaxNumInputChannels and JucePlugin_MaxNumOutputChannels while AU and RTAS uses JucePlugin_PreferredChannelConfigurations

How about allowing multiple channels configurations in VST as well?

IIRC one can also have different channel configurations in VST using setSpeakerArrangement():

I think we could agree on the following arrangements found in RTAS and use the corresponding ones in the VST SDK

kSpeakerArr30Cine 	//L R C
kSpeakerArr40Music 	//L R Ls Rs (Quadro)
kSpeakerArr50 	//L R C Ls Rs
kSpeakerArr51 	//L R C Lfe Ls Rs
kSpeakerArr61Music 	//L R Lfe Ls Rs Sl Sr
kSpeakerArr71Music 	//L R C Lfe Ls Rs Sl Sr

in VST there’s some potential ambiguity between the cine and music variants for the same number of channels though.

Yes, that’d be a good thing to support, and was already something on my list. Will check it out soon!

I’ll race you. I’m building speakers for surround.

I have some cool imaging going on in stereo: 3 band EQ where the bands are panned slightly differently, and the quieter channel of a panned signal is damped and delayed a bit, increasing the imaging definition. With computers getting so fast, processing subtle acoustic details is finally worth it.

Now it’s just a question of whether it works in surround, or causes infinite phasing problems!

Dave Heinemann

Great thing, cause now I’m forced to use an older version of the JAP.

I’m waiting for new releases.


On a related note: if I insert my JUCE plug in a 5.1 track, all 6 channels are affected simultaneously by it. What would I have to do to let it only effect the left and right channel?

Same thing for a mono plug inserted into a stereo track, btw. Both channels are routed through the plugin, which shouldn’t be the case.

Why shouldn’t it be the case? If you don’t want to affect some channels, just pass the data through them unchanged. At least you have the option of using it if you want to.

Okay, “shouldn’t be the case” is maybe a bit hard, but it seems that the JucePlugin_MaxNumInputChannels variable has no effect at all, which I find a bit weird…

Oh, I see what you mean. Sorry, I think I may have missed your point there.

But anyway, those min/max values are really just signals to the host about what your plugin wants. Some hosts might not be able to take such values, or could ignore them, so you should probably make your code flexible enough to deal with whatever gets thrown your way.

Well, the reason why I stumbled upon this is that a plugin user complained about a) all channels in a 5.1 environment going through the (stereo) plug in the Cubase routing diagram and b) Cubase 4 crashing on exit when the plugin was used in a 5.1 channel. I should mention that in processBlock only the first two channels are being used.

Now I have looked into the setSpeakerArrangement method in the juce_VSTwrapper and replaced this:

[code]// if this method isn’t implemented, nuendo4 + cubase4 crash when you’ve got multiple channels…

    numInChans = pluginInput->numChannels;
    numOutChans = pluginOutput->numChannels;

    filter->setPlayConfigDetails (numInChans, numOutChans,
    return true;


with this

if (pluginInput->type == kSpeakerArrStereo) return true; else return false;

and both the routing as well as the crashing problem are gone. Do you see any harm in this approach?

Well yes, if you replaced that whole function, then plugins that actually want 5.1 wouldn’t be allowed to get it, and like the comment says, would make nuendo and cubase crash internally!

What’s actually crashing? Is it in your code or the wrapper?

I think you got me wrong here… Cubase4 crashes when I DON’T replace the function (don’t know where exactly, as I don’t have Cubase4 myself, I have to rely on this user’s report). When I check for the kSpeakerArrStereo, the crash disappears.

Ok, but that’s for a stereo plugin, right? If you do a 5.1 plugin, it crashes without the function!

Right. So the setSpeakerArrangement function should probably be something like this:

if (pluginInput->numChannels == numInChans && pluginOutput->numChannels == numOutChans) return true;
else return false;

So if the plugin was intended to be 5.1, everything would be alright. And if not (as in case of a, say, stereo plug inserted into a 5.1 channel), only the L and R channel would go through the plugin and the rest will be bypassed. And no crash…

I’m not really following your logic. The call is there to tell the plugin how many channels it’s going to get. Ignoring it and returning false isn’t an option - you might get away with it in stereo mode, but it’s not a fix.

Your crash sounds like it’s caused by the plugin itself, not the host - maybe because it’s getting more channels than it expects, it’s corrupting some memory? Changing this method would force cubase to only send it stereo, which would seem to “fix” it, but if it’s an error in your code, it’d be missing an underlying problem.

It’s true that I can’t exclude that the cause for the crash lies within my code; however, the way I understand things setSpeakerArrangement is a question from the host to the plugin, a la: I know you are a stereo plugin, but would you agree with a 5.1 setting as well? If yes, return true and I will route all 6 channels through you. If not, return false and you will only get two channels (please excuse the personification… ). Therefore it still seems strange to me that the configuration originally intended by the developer (numInChans and numOutChans) is always overwritten at the moment.

Unfortunately the reality it goes more like this: “host asks if plugin can support 5.1… plugin returns false, host crashes and burns”…

So I just made the wrapper agree to whatever it’s given, and that’s how many channels you get. That way the host is happy, and the plugin can e-to-e or clear any channels that it doesn’t need.