VST/JUCE: Reaper's odd channel request behavior for 10 channels

[RDan]

Hey!

I am currently working on some Ambisonics plugins using the JUCE framework and i want them to automatically set the right Ambisonic order depending on the current bus size.
To clarify: different Ambisonic orders need a different number of channels: nCh = (order+1)^2 for 3D Ambisonics

This works quite nicely when "inform plug-in when track channel count changes" is activated for the plugin ( '+' ->' compatibility settings'). If so, each time the track's number of channels gets changed, Reaper sends a effSetSpeakerArrangement message to the plugin requesting a VstSpeakerArrangement with specific type and number of channel (e.g. for 2 channels: type = 1 (stereo), numChannels = 2).

But here is the problem: when i choose "10 channels" for the track, Reaper sends a request for type = 28 (this is kSpeakerArr102, using 12 channels) and a numChannels 10. As kSpeakerArr102 having 12 speakers, the plugin sends 0 (rejecting the request due to the numChannel mismatch) and Reaper starts another request for type = -2 (user defined, so everything possible) and a numChannel 64. As a result, my plugin sets the Ambisonics order to 7 ((7+1)^2 = 64).

For every other channel count, the speakerArrangementType request by reaper matches the requested numChannels. For higher numbers like 54, reaper sends - correctly - a user defined request (type -2), as there's no layout with 54 speakers.

So in my opinion this is a quite odd behavior, requesting a non-conform speakerArrangementType-numChannels-pair.

Is there a reason behind that? Or is it a bug, maybe a wrong line of code as type=28 would be correct for 12 channels (next to 10)?

Regards
Daniel

[Justin]

We send kSpeakerArr102 for anything 9-12 channels, since the VST spec doesn't define speaker arrangements for 10 channels. The numChannels field of VstSpeakerArrangement is probably the best choice for determining the exact channel count when you receive a kSpeakerArr102?

Though I see your point, we should probably send kSpeakerArrUserDefined for 10 channel mode too. Hmm.

[RDan]

Originally Posted by Justin

The numChannels field of VstSpeakerArrangement is probably the best choice for determining the exact channel count when you receive a kSpeakerArr102? .

Indeed, especially because my Ambisonics Plugins don't care about SpeakerArrangement types But intercepting the kSpeakerArr102 would involve changing the JUCE VST rapper (every time there's a new JUCE update).

Originally Posted by Justin

Though I see your point, we should probably send kSpeakerArrUserDefined for 10 channel mode too. Hmm.

I would appreciate this option a lot!

[RDan]

Sorry to bring up that old thread, but I experience a similar behavior with VST3 plug-ins. The highest number of channels I get is 24 (I suppose 22.2), even though the plug-ins supports up to 64 channels (worked fine with VST2).

This might be related to this thread: https://forum.cockos.com/showthread.php?t=214338

Is it the same culprit or is it a problem with the VST3 standard in general?

[RDan]

Another strange behavior I just experienced:
When I restrict the input channel count to be smaller or equal 2 channels, but let the output channel count be any arbitrary number of channels, I will get 2in/2out, even with a bus size of 64 channels.

With VST2 I'll get 2in/64out.

If there's no restriction at all, VST2 will give me 64/64, VST3 24/24.

[TBProAudio]

Does the VST3 24 IO channel restriction still exists? Any solution (Reaper or plugin code)? Thank you!

[TBProAudio]

OK, I debuged my plugin and Reaper 5.965 even further. It seems that Reaper never requests channel counts higher than 24 (== VST3: SpeakerArrangement k222), even if plugin reports a higher channel count. Is there anything I can do ? Thank you for any response.