I am working on a plugin that works with 24 channels. We are using REAPER as we are working on a custom layout.
However we noticed that the channels from REAPER do not reach the plugin in the expected order, and there is a swap after channel 20. I traced the problem to this switch case:
I am guessing REAPER just uses the formats from VST3 in order missing multichannel with ambisonics channels.
This breaks the channel mapping applying by JUCE.
Or am I missing something here?
A similar issue was discussed recently on github:
In short, I believe the current behaviour is working as intended.
I partially agree with you. Because I believe REAPER could do it in a way that would not lead to this conflit.
However these cases are a bit gray in term of VST3, because I do not think it would have been a multichannel format that would make sense here, maybe that why REAPER is ignoring the channels that it is passing to VST3 plugin.
Isn’t there a way to add a workaround here? What I did is replace the discrete0 with something that is between LFE2 (it is the one before that mono channel) and ambisonicACN0 so it is not put at the end.
My logic is that i first check if there is a mix of ambisonics and multichannels channel types. When there is I apply the workaround.
But I am not sure what I might be breaking.
For the record, I noticed similar problems with a VST3 plugin I develop when working with 10 channels in Reaper: channels 5 and 6 would get swapped with 7 and 8. Increasing the number of channels to 12, 14 and 16 no longer displays this problem. The VST2 version of the plugin does not cause any issues.
I see the same behavior with REAPER and scratching my head as to why. As far as I can tell, I’m correctly handling all of the AudioChannelSet mapping, but when I set the channel count to 8 or 10 in REAPER, channels 5/6 are swapped with 7/8 (swapping sides/rears). Setting the channel counts to 12+ in REAPER gives the expected results.
In the debugger, I am populating what should be the correct channel in the processBlock buffer according to the AudioChannelSet, but in REAPER it seems to be remapped?
Did you ever find a resolution to this?
Hello,
Our solution was to bypass the VST3 → JUCE channel mapping if the DAW is REAPER.
It is not a clen solution but I could not rely on the AudioChannelSet information as we need to order the channel for an internal buffer.
I tried something similar. I wrote a remapper that undoes the channel mapping JUCE applies. It’s not a great solution because the audio gets mapped twice, but at least the inputs are one-to-one. Is this how you did it or did you patch the
JUCE wrapper?
I patched the JUCE VST3 wrapper from JUCE. I was not sure if I could remap it back.
However, we also apply a second remap from JUCE to our internal buffers.
