Nuendo 11 wrong channel layouts

After tackling Logic here are some findings for Nuendo (Mac)

Everything seems to be ok except 7.x (music)

7.0 and 7.1 seem to have wrong naming in the surround channels, the pairs side and rear are swapped according to the nuendo own meter plugin SuperVision

Apart from that, all the Auro formats and 22.2 is reported as unknown…

Another one. Just go through the channels and you will see that wrong channels are triggered. Also the channel order in the SurroundTutorial Plugin does not concur with the code below nor with the Nuendo order.


AudioChannelSet AudioChannelSet::create7point1point6() { return AudioChannelSet ({ left, right, centre, LFE, leftSurroundSide, rightSurroundSide, leftSurroundRear, rightSurroundRear, topFrontLeft, topFrontRight, topSideLeft, topSideRight, topRearLeft, topRearRight }); }

Now for 7.1.4:

AudioChannelSet AudioChannelSet::create7point1point4() { return AudioChannelSet ({ left, right, centre, LFE, leftSurroundSide, rightSurroundSide, leftSurroundRear, rightSurroundRear, topFrontLeft, topFrontRight, topRearLeft, topRearRight }); }

And now for 7.1.2:

AudioChannelSet AudioChannelSet::create7point1point2() { return AudioChannelSet ({ left, right, centre, LFE, leftSurroundSide, rightSurroundSide, leftSurroundRear, rightSurroundRear, topSideLeft, topSideRight }); }

The following layouts also do not work correctly in Nuendo. At least one channel does not pass audio.

8.0 Cine
8.0 Music

Hi @reuk ,

any news? It is quite urgent since I want to release these days with everything working.



I’ve put together a change that is intended to fix the channel-ordering problem. However, it’s quite a significant rewrite of the VST3 channel handling code, and it will need careful review and thorough testing to ensure that no regressions have been introduced. At the moment I expect it will be released in the next week or two, but that might get pushed if any issues are discovered that require further changes.

After adding a plugin to a rack in Nuendo, a number of inputs/ouptuts might be left disconnected. You can see the current routing configuration by clicking on the “Routing” tab in the Channel Settings window. Then, you can click on a particular plugin to change its routing. I found that by setting the SurroundPlugin to “Mono” and then to the intended layout, all channels could be made to work properly. The same issue seems to affect the built-in plugins, so I’m confident this issue is in Nuendo, and not in JUCE.

In this screenshot, you can see that both “SurroundPlugin” and “SuperVision” are set to only process three out of four channels immediately after loading the channel strip. I could get them both to work as expected by manually setting them to use a four-channel layout.

If you’ve double-checked that all inputs and outputs are connected in the routing view, and any channels are still failing to pass audio, then please let us know and we can investigate further.

Thanks for the tip with the routing editor. That was it. So it seems that there is a bug in Nuendo with loading insert setups.

@reuk Any news on the VST3 rewrite?

We’ve added changes on develop to map properly between the host layout and JUCE layout in VST3 clients:

We’ve also added similar changes for JUCE VST3 hosts:

Finally, both channel mapping implementations are tested here:

1 Like

Thanks. Gonna test it.

@reuk In Nuendo everything seems to work so far. But in Reaper things get crazy when using channel counts greater than 20 on a VST3. On Mac one could evade to AU but not on Windows. Could you please have a look and tell me who is the culprit? Juce, VST3 or Reaper? It should be easily visible using a generator and Surround Tutorial.

Please can you be more specific about the behaviour you’re currently seeing, and how it differs from the behaviour you’d expect to see?

I gave this a quick test by putting two instances of the SurroundPluginDemo in series on a single channel. Setting both instances to have 32 ins and outs worked fine: clicking one of the output channel buttons in the first instance caused the level meter on the corresponding channel in the second plugin instance to move.

Using more than 32 channels caused an assertion to fire in JUCE’s VST3 wrapper. The SurroundPluginDemo has two input buses and two output buses, and requesting 48 channels will cause REAPER to call the plugin’s setBusArrangements with 48 channels per bus. However, when processing, REAPER doesn’t honour this arrangement, and instead sends 48 channels on the first bus and 16 channels on the second bus. This is an issue with REAPER, not with JUCE.

Also note that REAPER doesn’t seem to honour the channel ‘type’, and always just sets the lowest bits of the channel-type bitfield. As a result, the channel types may not be particularly meaningful in REAPER.

Hi @reuk ,

ok, what i would expect is the following. Create a track with say 24 channels. Load a tone generator and after that a surroundtutorial plugin.

Open the Plug-in pin connector of the generator and let it only output on channel 20.

Now if you look at the surround tutorial you will see that the last channel, 24, is lit. If you change the track width to lets say 28, you will see that again the last channel, now 28, is lit.

This is only one example. I know that the sound after surroundtutorial is again on the right channel. But from inside the plugin i would have to do some hacky stunts for every possible channel config in reaper to get something predictable.

So my question is, is Reaper the culprit? And if so, what would be a good fix? Could the channels be treated as just discrete with numbers when having the combination of Reaper and VST3?

Hi @reuk ,

any news on that?



Sort of, but it’s partly due to the VST3 spec. VST3 only has named speakers and not discrete/numbered channels. Meanwhile, REAPER appears only to have numbered channels. If you request an 8-channel track in REAPER, it will just set the 8 lowest bits of the channel bitset, which may not make sense when interpreted as a VST3 speaker layout.

Ideally, the VST3 spec would be extended to include a way of specifying discrete channels as well as named channels, and REAPER would implement that new API.

They could, and that might work for now, but it would break if REAPER is ever updated to use the VST3 API in the way it was intended. That is, if a future version of REAPER was extended to have proper surround layout support, then the plugin would no longer work in that version of REAPER.

Hi @reuk

thanks for the reply. In any case, if I implement some kind of manual fix, that would break once Reaper gets changed/fixed in that regard. So, I would like to create a manual fix because on Windows I cannot tell my users to use AU instead of VST3. I think the most straight forward solution would be to access the channels as discrete ones and when Reaper fixes it sometime in the future, well then I have to do that too. Could the access to the channels in this way be provided by Juce?