Adding parameters post launch to a plugin?

Have a short question related to JUCE parameters in v6

I’m doing some tests here and adding new parameters to the plugin breaks automation even with the JUCE_FORCE_USE_LEGACY_PARAM_IDS=0

So post launch, if we add a parameter to the plugin regardless of legacy param ids or not, it will break automation in Logic?

I can’t reproduce this behaviour using new-style param IDs.

I’m testing with JUCE 6.0.8 (9ac96840a) and Logic 10.6.3.

My steps to test:

  • Build the AudioPluginDemo as an AU
  • Load the plugin in a logic project, and save some automation for both parameters
  • Quit Logic
  • Add a third parameter to the plugin and rebuild
          : AudioProcessor (getBusesProperties()),
            state (*this, nullptr, "state",
                   { std::make_unique<AudioParameterFloat> ("gain",    "Gain",              NormalisableRange<float> (0.0f, 1.0f), 0.9f),
                     std::make_unique<AudioParameterFloat> ("delay",   "Delay Feedback",    NormalisableRange<float> (0.0f, 1.0f), 0.5f),
                     std::make_unique<AudioParameterFloat> ("another", "Another Parameter", NormalisableRange<float> (0.0f, 1.0f), 0.5f) })
  • Open the saved project in Logic.

When I carry out the steps above, the automation data is recalled correctly.

Note that the param IDs for all parameters must be identical across versions. This means that if you were previously using legacy param IDs, you must continue to use legacy IDs; if you were previously using non-legacy IDs, you must continue to use non-legacy IDs.

To provide more suggestions, I think I’d need more information about your project. How are you adding parameters to the plugin? Are you sure that you’re not inadvertantly modifying existing param IDs when you add new parameters?


This is strange behavior. Is it possible that the int hash of the parameterID string just happens to mean that the unordermap is maintaining the correct order by chance? When you move into a more production situation where you 100s of parameters, then it starts to show up.

I’m experiencing the same behavior as highlighted in this thread:

“The reason AudioUnit (certainly in Logic Pro, although I’m surprised the JUCE host is doing the same) is showing you the parameters in a different order is because it lists them by alphabetical ID, rather than in the order declared by the plug-in. This also adds the restriction that any new parameters added must list “alphabetically higher” than existing IDs (e.g. “aaaa”, “aaab”), otherwise your automation will be messed up. So Logic will introduce this problem for you either way, unless you create some space between the IDs you use (e.g. “aaaa”, “bbbb”, etc.)."

Thanks, I just tested this in the DSPModulePluginDemo (with 60 parameters) and adding a new parameter does indeed change the assignment of existing automation data in Logic. I’m investigating now.

I’ve done a bit more digging. At the moment, I’m inclined to say that this behaviour is a bug in Logic.

According to the the documentation for the AudioUnit framework, “An audio unit parameter is defined by the triplet of audio unit scope, element and parameterID.” When adding a new parameter to a JUCE plugin, the scopes, elements, and IDs of all existing parameters are unaffected, so I think Logic should treat these as the “same” parameters.

When I tested some other hosts (Live 11.0.6 and Reaper 6.34), they recalled automation correctly after adding a parameter, so the issue only seems to affect Logic.

I noticed that the implementation of the kAudioUnitProperty_ParameterList property was returning a sorted list of AudioUnitParameterID. If I change the implementation to return the IDs in the order that the parameters were originally added to the plugin, then automation recall works correctly in Logic - as long any “new” parameters are added at the end of the list. Perhaps Logic is storing an index into this parameter list instead of storing the parameter’s ID.

I’ll file a bug report with Apple and see what they say.


Thanks @reuk!

It is definitely a major issue as it means something as fundamental as the parameter system is more or less not working as it is supposed to. Hopefully Apple get back with a solution.

Prior to switching to the new JUCE parameter system, we were maintaining versioning over the parameters, if say we added a parameter in v1.1, we’d pass in the version number at construction and we would then sort the list based on versioning before reporting to the DAW.