BUG: Nuendo 13 and Juce for 9.1.6 and 9.1.4

[fiedleraudio]

@reuk Will it be possible to get this also into Juce 7?

[reuk]

It’s currently on the develop branch, which is based on 7.0.12.

[PeterRoos]

@reuk

As mentioned already, support for the new Atmos layouts is added in this commit:

Thanks again, @reuk !

The comment in Juce_AudioChannel.h has a typo in the order for the top layer (ITU 9.x.6)

topFrontLeft, topRearRight, topFrontRight, topRearRight,

The create function is ok

[fiedleraudio]

@reuk So a cherry pick to the release version of 7.0.12 should do, right?

[Verbonaut]

Bear in mind one of the commits before this one is a VST SDK update, so that might be a lot of cherries.

[fiedleraudio]

@reuk Ok, my question was rather if it will be added to a possible 7.0.13 master? Updating to 8 at this moment would be a significant setback in our release schedule.

[Verbonaut]

I’m sure they’ll offer a .13 wrap-up of v7 dev when v8 is launched, I’d be interested to know how much additional change we can expect to see between the current dev and the final v7. I’m guessing not much, but if there’s anything significant planned in terms of fixes it would be good to know fairly soon so we can hop on to this as it stands or whether it would be best to give things a little more time to settle.

[reuk]

Thanks, the typos are now fixed:

AudioChannelSet: Fix typos in comments

[fiedleraudio]

Great, thank you.

But again the question, no Juce 7.0.13 with that fix for us who cannot yet upgrade to 8?

[reuk]

You can treat the final commit before JUCE 8.0.0 as 7.0.13. We don’t plan to release any further commits on JUCE 7.

[fiedleraudio]

Ok, but what about the license? We do need to pay an upgrade right now, right?

[reuk]

Anything before the first JUCE 8 commit is covered by the JUCE 7 license.

If you’re in doubt, check the license headers in the JUCE version that you’re using.

juce_audio_plugin_client.h @ 16dac4a, uses JUCE 7 license, links to the juce-7-licence page (if you scroll down a bit in the file, you’ll see that the ‘version’ field inside the JUCE module declaration is 7.0.12).

juce-framework/JUCE/blob/16dac4aeb2c65fdce45d19325ad9789a76937a02/modules/juce_audio_plugin_client/juce_audio_plugin_client.h#L13

juce_audio_plugin_client.h @ 2fc069b, uses JUCE 8 license, links to the juce-8-licence page, has a module version of 8.0.0.

juce-framework/JUCE/blob/61a03097ec9e01693c87ac71935e97b9714cff1a/modules/juce_audio_plugin_client/juce_audio_plugin_client.h#L19

Another place to check is the definition of JUCE_MAJOR_VERSION in juce_StandardHeader.h. If the MAJOR_VERSION is 7, you need to follow the licensing rules for JUCE 7. if the MAJOR_VERSION is 8, you need to follow the licensing rules for JUCE 8.

[PeterRoos]

Thanks again for this last minute surround fix, also because I recently switched to the 7 perpetual license. I do not need Juce 8 features at the moment, and I wanted to use the more permissive 7 license.

Finishing my first surround/atmos plugin at the moment

[fiedleraudio]

Thanks.

[fiedleraudio]

Hell, i am getting a headache realizing what a problem the old way of Juce of reframing the ITU setup as an Atmos setup now causes.

Old plugins work just fine when a Nuendo 12 session is loaded into Nuendo 13.

But when built with the updated Juce, everything becomes a mess because our presets are based on the Atmos setup channel order but now we get a different channel order due to ITU setup, both in Nuendo 12 and 13.

So to make that work for the user without breaking their sessions and at the same time being able to offer both Atmos and ITU setups, we have to completely abandon juce::AudioChannelSet for use in our plugin code and roll our own class for speaker layouts. That could have been avoided if the 9.1.6 and 9.1.6 ITU layouts had the same Atmos channel order, only with the difference in naming (e.g. L<->LC, LW<->L etc.).

I’d call that a breaking change.

[reuk]

@fiedleraudio

So to make that work for the user without breaking their sessions and at the same time being able to offer both Atmos and ITU setups, we have to completely abandon juce::AudioChannelSet for use in our plugin code and roll our own class for speaker layouts.

I don’t know how your plugin works, but I wonder whether it’s possible to just do the mapping as a one-off operation. i.e. if the preset is ‘old’ and the channel layout is detected as ITU, remap the channels in the preset to be consistent with the new ITU layout before applying the preset.

@fiedleraudio

That could have been avoided if the 9.1.6 and 9.1.6 ITU layouts had the same Atmos channel order, only with the difference in naming (e.g. L<->LC, LW<->L etc.).

AudioChannelSet is always ordered according to the enum values in AudioChannelSet::ChannelType. There’s no way to apply an arbitrary order to the contained channels.

@fiedleraudio

I’d call that a breaking change.

This change is mentioned in the breaking changes doc in the JUCE repo. Unfortunately I don’t think there’s a good solution to this problem. If we want to differentitate between ITU and Atmos layouts, then we need to supply two different AudioChannelSets for those layouts, and due to the way that AudioChannelSet works, the ‘relative orders’ of the channels in those layouts may differ.

[fiedleraudio]

@reuk

I don’t know how your plugin works, but I wonder whether it’s possible to just do the mapping as a one-off operation. i.e. if the preset is ‘old’ and the channel layout is detected as ITU, remap the channels in the preset to be consistent with the new ITU layout before applying the preset.

Remapping presets is not an option as there might be also user presets with unknown content and the possibility of free internal routing. I will rather have to reorder the channels so that the ITU order matches the Atmos order (as much as possible). That will require a remapping class of some sort.

I must make sure that plugins behave old when loaded in from an already existing session, but are also capable of showing what is when newly instantiated. This in combination with routing presets and overall consitency across products is far from trivial.

The main problem here is: Session saved in Nuendo 12, plugin is presented with Atmos channel order. Same session opened in Nuendo 13, plugin is presented with ITU order. I was wrong in my last post about old plugins.

@reuk

AudioChannelSet is always ordered according to the enum values in AudioChannelSet::ChannelType. There’s no way to apply an arbitrary order to the contained
…
This change is mentioned in the breaking changes doc in the JUCE repo. Unfortunately I don’t think there’s a good solution to this problem. If we want to differentitate between ITU and Atmos layouts, then we need to supply two different AudioChannelSets for those layouts, and due to the way that AudioChannelSet works, the ‘relative orders’ of the channels in those layouts may differ.

Since AudioChannelSet depends on this order enforced by the BigInteger bit magic, it will be impossible here. A simple std::vector< juce::AudioChannelSet::ChannelType > would have been better for many reasons.

[Verbonaut]

Could you not just check if your recalled state’s enums include leftCentre/rightCentre or wideLeft/wideRight and then you know if your 9.1.6 session needs to be remapped, because that gives you all you need to know to disambiguate if your N12 era 9.1.6 session was an ITU or non-ITU variant? At that point you’re good to go on a one-time remapping of the session data and can continue to use the channel layout method.

[fiedleraudio]

@Verbonaut Yeah, i finally will do a check if the state is an old one or a new one, by checking if a value which i will introduce in the new version of the plugin is present in the plugin state. Thereby i will be able to distinguish between two methods of handling the new ITU layouts in juce. The repercussions regarding programming effort are substantial though…

[fiedleraudio]

One more thing you might want to add to the comment in juce::AudioChannelSet is that not only front speaker designations are different between (Atmos) and (ITU) but also the designations for the rear surrounds. For the sake of completeness.