Can't see automation parameters in active side of Plug-In Automation window JUCE 5 to 6 upgrade

General JUCE discussion
1

Hello Guys,

I have a project that compiled with JUCE 5. Now I’ve upgraded the project to JUCE 6. Everything seems fine, all parameters work correctly and their values getting right. But in Pro Tools, Plug-In Automation window show the parameters in the “remove” side.

In the pro tools project I save all parameters with “Add” part of the Plug-In Automation window with the JUCE5 version of the plugin. After that, I change JUCE6 version of the plugin and open the project. I see all parameters in the “remove” side of the Plug-In Automation window.

If I move the parameters from “remove” to “add” part and save it with JUCE6 version of the plugin, it works. Next time when I open the pro tools project, I see the right things.

I looked for the isAutomatable() function and saw that it always return true.

What would cause this? Any idea?

Volkan

2

I don’t think that isAutomatable is the cause of the problem. If I set isAutomatable to false in a test plugin, then the parameters don’t show up at all in the “Plug-In Automation” window.

It would be helpful to know a bit more about your testing setup. In Pro Tools’ “Mixing” preferences, have you enabled “Plug-In Controls Default to Auto-Enabled”? Do you see different results if you record some automation data for some of the parameters before changing the plugin version? Does automation data recorded with the JUCE 5 plugin restore successfully when switching to the JUCE 6 plugin?

If automation data is being recalled correctly and only unused parameters are being moved to the “remove” column, then I’m not sure there’s anything we can do in JUCE. I don’t think the AAX SDK provides a way of controlling whether automation is enabled or disabled for a particular parameter.

If automation data is not being recalled correctly at all, then my best guess is that the different versions of the plugin may also have differing parameter IDs. It would be useful to know a few more details about your project, and in particular how you are managing parameters. Are you using the AudioProcessorValueTreeState, or AudioProcessorParameters, or the old virtual parameter functions on AudioProcessor? Are you using any preprocessor flags which affect parameter IDs (e.g. JUCE_FORCE_USE_LEGACY_PARAM_IDS). Did you have to make any changes to your plugin’s source code during the upgrade to JUCE 6?

3

Hello @reuk, thanks very much for your reply.

Long story short, the protools project doesn’t open the automation parameters (In your way of saying, the automation data is not being recalled at all). But If I don’t use automation and just save the project with parameter settings, it does correctly recall the parameter values. If there is a parameter id mismatch, would it be possible?

I use AudioProcessorParameters but I use my own implementation of AudioParameters like AudioParameterFloatVk which makes possible to call a function automatically when setValueNotifyingHost() called. The implementation is here: GitHub - volkoaudio/JUCEvk: Some classes for JUCE library

I suspected that it would be the reason for that problem and I changed all AudioParameterFloatVk class with AudioParameterFloat class. It didn’t change the result but of course I didn’t change JUCE5 version of the plugin with AudioParameterFloat. Then, this doesn’t entirely count.

I don’t use any preprocessor flags like JUCE_FORCE_USE_LEGACY_PARAM_IDS for the parameters.

I did change some of the code but took back to make the test more clearly for this issue. Now, I use the same code for parameter testing.

4

It seems I should use JUCE_FORCE_USE_LEGACY_PARAM_IDS preprocessor define. Now, I see automation parameters on the “Add” section of the Plug-In Automation window.

BTW, is there an upgrade document? If there is, I would like to use it for after upgrade reference document.

5

That does sound as though the parameter IDs are being retained somehow. Now I’m really unsure why Pro Tools would be disabling the parameters!

I had a quick look at the code, and it appears that your parameter classes derive publicly from AudioProcessorParameterWithID, so I would expect the parameter IDs to be reported correctly to the host.

If you weren’t previously using legacy IDs, I would expect enabling that flag to break saved automation. That is, any automation you saved with a previous version of the plugin might not be recalled correctly. Therefore, I don’t think this is a good solution to the problem.

Have you checked the Pro Tools logfile? There’s a chance that Pro Tools is encountering some sort of error when loading your plugin. In this case, it might write some diagnostic output to the logfile.

On my system, the logfiles are found at /Applications/Logs/Pro_Tools_...txt. According to Avid’s help pages, they might also be found at ~/Library/Logs/Avid or ~/Library/Logs/AvidLogFiles.

All breaking changes are recorded in the BREAKING-CHANGES.txt document in the JUCE repo.

6

I had a quick look at the code, and it appears that your parameter classes derive publicly from AudioProcessorParameterWithID, so I would expect the parameter IDs to be reported correctly to the host.

That’s nice to hear. I don’t know very much JUCE’s parameters’ background.

If you weren’t previously using legacy IDs, I would expect enabling that flag to break saved automation. That is, any automation you saved with a previous version of the plugin might not be recalled correctly. Therefore, I don’t think this is a good solution to the problem.
Have you checked the Pro Tools logfile? There’s a chance that Pro Tools is encountering some sort of error when loading your plugin. In this case, it might write some diagnostic output to the logfile.
On my system, the logfiles are found at /Applications/Logs/Pro_Tools_...txt . According to Avid’s help pages, they might also be found at ~/Library/Logs/Avid or ~/Library/Logs/AvidLogFiles .

Actually I test it with the automation parameters and data and everything works correctly with old style parameters flag. I’ve also checked the BREAKING-CHANGES.txt document. I expected it’s changed in JUCE 5 to 6 but I see the comments in JUCE 4. Than, I’ve checked our juce project file if we were create JUCE 4 but I found that we created the project JUCE 5. It seems weird.

I understand what you mean, I shouldn’t use old style parameters flag to suppose the project is OK. Than, I’ve just looked at the logs as you suggest and found that lines after our plugin loaded

3671.938057,00307,0033: SMgr_DSPCache::InstantiatePlugIn - pluginType: Native, name: "PluginName", track "Audio 1_01-26.1"
3671.957091,00307,0e0f: CMN_TRACEASSERT controlNum>0 /Users/autobld/gitlabci/PT/release/2021/r2/ProTools/NewFileLibs/SMgr/SMgr_PlugInInstSet.cpp line 1814
3671.957102,00307,0e0f: CMN_TRACEASSERT controlNum>0 /Users/autobld/gitlabci/PT/release/2021/r2/ProTools/NewFileLibs/SMgr/SMgr_PlugInInstSet.cpp line 1814
3671.957108,00307,0e0f: CMN_TRACEASSERT controlNum>0 /Users/autobld/gitlabci/PT/release/2021/r2/ProTools/NewFileLibs/SMgr/SMgr_PlugInInstSet.cpp line 1814
3671.957121,00307,0e0f: CMN_TRACEASSERT controlNum>0 /Users/autobld/gitlabci/PT/release/2021/r2/ProTools/NewFileLibs/SMgr/SMgr_PlugInInstSet.cpp line 1814
3671.957127,00307,0e0f: CMN_TRACEASSERT controlNum>0 /Users/autobld/gitlabci/PT/release/2021/r2/ProTools/NewFileLibs/SMgr/SMgr_PlugInInstSet.cpp line 1814
3671.957133,00307,0e0f: CMN_TRACEASSERT controlNum>0 /Users/autobld/gitlabci/PT/release/2021/r2/ProTools/NewFileLibs/SMgr/SMgr_PlugInInstSet.cpp line 1814

I searched about CMN_TRACEASSERT and found only two links with google. Do these log lines any sense to you?

7

This suggests that the previous version of the plugin that you shipped might have had the flag enabled, perhaps accidentally. I’d receommend checking out the previous version of the project and grepping carefully for the LEGACY_PARAM_IDS flag. If this flag was enabled for the previous version, that would explain the behaviour you’re seeing.

Normally this flag would apply to all plugin builds (AU, VST3). Have you also been testing other versions of your plugin? When the LEGACY_PARAM_IDS preprocessor define is enabled, are you able to correctly open projects which used the JUCE 5 version of your VST3?

If enabling legacy param IDs fixes the AAX plugin but breaks your other plugin types, then I’ll be very stumped! This would probably indicate a regression in JUCE’s AAX wrapper…

This log snippet certainly looks like Pro Tools is encountering some sort of issue after loading your plugin, but unfortunately the errors seem to be coming from Pro Tools rather than from inside the plugin so I’m not sure what they mean. It’s a good idea to try to fix these assertions though.

You could try contacting Avid’s developer support - hopefully they’ll understand the log messages, and be able to give you some advice to avoid those warnings. They might also be able to explain why the plugin parameters are defaulting to disabled. There’s a developer forum here, and another one here. If you have an email contact you could try that too.

8

This suggests that the previous version of the plugin that you shipped might have had the flag enabled, perhaps accidentally. I’d receommend checking out the previous version of the project and grepping carefully for the LEGACY_PARAM_IDS flag. If this flag was enabled for the previous version, that would explain the behaviour you’re seeing.

I think that solves the questions. I found these lines in the JUCE 5 project:

Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1239:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1310:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1380:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1448:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1510:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1571:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1640:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1704:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1819:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",
Builds/MacOSX/ProjectName.xcodeproj/project.pbxproj:1884:"JUCE_FORCE_USE_LEGACY_PARAM_IDS=1",

JuceLibraryCode/AppConfig.h:146:#ifndef    JUCE_FORCE_USE_LEGACY_PARAM_IDS
JuceLibraryCode/AppConfig.h:147: //#define JUCE_FORCE_USE_LEGACY_PARAM_IDS 0

I don’t know how it happened but we know the reason now. I’ll use the old style parameter flag.

JUCE_FORCE_USE_LEGACY_PARAM_IDS

Thanks very very much again @reuk I really appreciated your help.

Volkan