Backwards compatability issue with AAX moving from JUCE 5.4.3 to JUCE 5.4.4

Audio Plugins
1

Hi all,

Seeing an issue when upgrading from 5.4.3 to 5.4.4.

In Pro Tools, now all the sessions created with my plugin with our 5.4.3 panner are now incompatible with 5.4.4. The automation lanes are disabled, and no automation previously recorded will play back.

The only changes in our code is code to comply with the JUCE upgrade (moving to unique_ptrs for our audio processor graph, for example).

Is there anything that happened in this version that would affect this? Or has anyone seen anything similar, the release notes are:

Version 5.4.4

  - Improvements to floating point number printing

  - Faster plug-in parameter indexing

  - Added support for persisting attachements to MIDI devices

  - Refactored Linux event loop handling

  - Multiple C++ modernisation improvements to the API

  - Added support for macOS 10.55 and iOS 13

  - Added support for Visual Studio 2019

  - Removed support for Visual Studio 2013

Possibly “Faster plug-in parameter indexing” is the issue?

2

Is the issue still present in 5.4.7?

3

Yes it is. Originally we were moving from 5.4.2 to 5.4.7, I just isolated it to 5.4.4 as the breaking change

4

Would it be possible for you to narrow if down a little further? There are a lot of parameter handling changes between 5.4.3 and 5.4.4 so it’s difficult to see what might be the culprit.

5

I’ll try to see if the problem exists in any of the demo code as well.

Other factors that may be a part of this:

  • we are using the Audio Processor Graph model, so we have 3 processors that are in serial, feeding into the next one in the chain
  • when instantiating, we create 3 groups of parameters (one for each node) using the AudioProcessorParameterGroup
  • I haven’t confirmed that 100% of our automation is broken, but all AudioParameterFloat are definitely broken

Does this ring any bells? I’ll spend some time today trying to get one of the demos to have this behavior as well

6

You may want to try git bisect to find the commit which introduced the bug

3 Likes
7

@chkn thank you for an incredible tip! I had no idea this existed!

@t0m git bisect points to this commit https://github.com/WeAreROLI/JUCE/commit/103bb5768851f962ba4995b37e089c622af526ee

Any thoughts on if this is something we are doing wrong, or a bug in JUCE?

8

I guess you need to enable JUCE_FORCE_USE_LEGACY_PARAM_IDS in the juce_audio_plugin_client module.

9

@McMartin this plugin has already been released, I’m trying to look through it right now and understand the ramifications of enabling this option for the future and backwards compatibility of our plugin.

Do you have any insight there? Is there something we will be missing by moving to JUCE_FORCE_USE_LEGACY_PARAM_IDS?

10

@apple412 I can’t guarantee that enabling JUCE_FORCE_USE_LEGACY_PARAM_IDS won’t break your plugin in some unexpected and subtle way.

However, for the AAX format, it seems that JUCE_FORCE_USE_LEGACY_PARAM_IDS only has an impact on the getParamID function whose behavior changed in the commit that you found using git bisect.

If you are releasing your plugin in other formats (AU, AUv3, VST3, …), enabling JUCE_FORCE_USE_LEGACY_PARAM_IDS might break things that were working fine. You then might have to use 2 separate projects, one for the AAX format where JUCE_FORCE_USE_LEGACY_PARAM_IDS is enabled, and one for the other formats where it is disabled.

1 Like
11

Unfortunately this is a bug-fix that has bitten you here, rather than a bug we’ve introduced. It’s difficult to see a nicer solution that the one @McMartin has proposed.

The commit that’s causing trouble shows the change fairly clearly - previously recorded automation is expecting String (idx) for the parameter IDs, whereas JUCE is now (correctly) getting the ID from the parameter.

1 Like
12

Ah, that’s too bad.

Thanks for the help everyone, we will come up with a good solution that works for us!! Very much appreciate the help. :smile: