[Bug]: Channel order incorrect from channel 20 and above in Juce 7.0.7 on VST3

[ValleyAudio]

Detailed steps on how to reproduce the bug

I have created a VST3 plugin based on the Surround Plugin example (renamed to Channel Tester). I have tested the plugin in Reaper with it inserted on a track. When the track width is more than 20 channels wide, the channel order stops being canonical from channel 20 and above. It seems that channel 20 is routed to the last channel, then 21 goes to 20, 22 to 21, 23 to 22, etc. Please the screenshot below

I.e. the order on a 24 channel track is something like 1, 2, 3, 4, ..., 19, 24, 20, 21, 22, 23.

This behaviour happens on any channel width greater than 20.

What is the expected behaviour?

The expected behaviour is canonical channel count, i.e. 1, 2, 3, 4, ..., 19, 20, 21, 22, 23, 24 etc regardless of track width.

Operating systems

Windows, macOS

What versions of the operating systems?

macOS: 12.6.2
Windows: 11, version 22H2

Architectures

x86_64, ARM

Stacktrace

No response

Plug-in formats (if applicable)

VST3

Plug-in host applications (DAWs) (if applicable)

Reaper

Testing on the develop branch

I have not tested against the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[reuk]

The root of the problem is that VST3 has both a "centre" Speaker and a "mono" Speaker, but JUCE only has a "centre" ChannelType. In a VST3 plugin, the "mono" channel is represented by the 20th bit of the SpeakerArrangement.

In the case you've reported, Reaper tries to use a bus arrangement with both the "centre" and "mono" channels enabled. JUCE handles this by remapping the "mono" channel to the discreteChannel0, which has the largest value out of all the named ChannelTypes. The other Speakers in the VST3 layout all have a direct counterpart ChannelType, so those get mapped to the corresponding JUCE ChannelType in the expected way. The '20th' channel appears in the final channel of the AudioBuffer because its ChannelType has the largest value after remapping.

Although potentially surprising, I believe that this is functioning as intended.

You normally shouldn't depend on channel order inside a VST3 plugin; instead, use AudioChannelSet::getTypeOfChannel to find the kind of channel at each index, and display channel names rather than channel numbers.