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.

7.1.6:

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.

LCRS+LFE
LRS
LRS+LFE
8.0 Cine
8.0 Music

Hi @reuk ,

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

Best,

Thomas

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?

Best,

Thomas

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?

Best,

Thomas

He @reuk,

In these change why is the 9.1.6 mapping the wideLeft where it seems like the Left is. Did some tests with 9.1.6 and an audio with only sample in the first and second channels (left and right) those does not appear on the first and second channels of the audio buffer provided in the processBlock.

What am I missing here?

Thanks in advance. Regards,
Joao Carreira

VST3 speaker arrangements can only be specified using a fixed set of positions, as shown here:

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Change+History/3.0.0/Multiple+Dynamic+IO.html#how-are-the-different-speakers-located

The front speakers appear in the order “left, left-centre, centre, right-centre, right”.

In a physical 9.1.6 setup, the outer front speakers are not really positioned at the normal locations for “left” and “right” speakers. Instead, the speakers appear in the order “wide-left, left, centre, right, wide-right”, where the “wide” speakers are positioned outside the normal “left” and “right” speakers.

The JUCE layout attempts to mirror the physical layout, by using “wide” speakers and omitting the “left-centre” and “right-centre” speakers. Then, the channels are mapped based on their locations. This means that the left-most JUCE channel (wide-left) maps to the left-most VST3 channel (left), the second left-most JUCE channel (left) maps to the second left-most VST3 channel (left-centre), and so on.

Thanks for the reply I so short notice @reuk.

I agree with the approach from JUCE to not map it to the left center and do it to the wide left instead.

However, although the diagram of VST3 shows the left center in between left and center, what I am seeing NUENDO 12 doing is putting the left channel actually in the left channel, not in the left center (which is the inner most channel).

At least, the samples put in the left and right channels (VST3 buffer) are the first two channel of the audio clip/file.

I believe they call it left center but it actually corresponds to the channel between the left and the left side surround.

I just tested out the SurroundPlugin demo in Nuendo 12. I believe it is behaving as intended.

Playing audio on the left channel in Nuendo appears on the wide-left channel in the JUCE plug-in:

Playing audio on the left-centre channel in Nuendo appears on the left channel in the JUCE plug-in:

For a more graphical view, I also tried playing audio on all channels through the VST MultiPanner, and then soloing the left channel, which produces audio on the wide-left channel in JUCE:

And soloing the MultiPanner’s left-centre produces audio on JUCE’s left channel:

Hopefully that helps to clear things up. Please let me know if you still have questions. If possible, please include a screenshot of the behaviour you’re seeing. The built-in MultiPanner and SuperVision plug-ins, and JUCE’s SurroundPlugin can all be helpful to diagnose the channels on which audio is playing.