Automation broken with JUCE 5.4 when LEGACY_PARAM_IDS enabled

I’m having the problem that automation does not work anymore on some of our plugins with the latest release. I can load my presets and all parameters notify the right way, but i don’t receive any notifications from the host.
The parameters are there in the hosts but nothing happens when i try to automate them. I don’t get any notifications and also the sliders do not move. The special thing is that that this does not happen in all our plugins that use the latest juce version and the vst versions seems to work. Maybe i do something wrong while setting up parameters.

Here is how i init them in the audio processor constructor:

treeState = new AudioProcessorValueTreeState(*this, nullptr);

using Parameter = AudioProcessorValueTreeState::Parameter;
auto parameter = treeState->createAndAddParameter(std::make_unique<Parameter>(paramName, text, String(), NormalisableRange<float>(fromValue, toValue), defaultValue, valueToTextFunction, nullptr, isMetaParam));
treeState->state = ValueTree("MyValueTree");

Does anyone have an idea what i’m doing wrong.

  • I’d suggesting bisecting on JUCE to find what specific change caused things to break
  • I’m guessing (but don’t count on the guess being right) that the parameter ids changed from integers to something fancy and that there might be a #define or option added in JUCE to keep the old behavior

Thanks for the tip. It’s exactly something like this. When i disable


automation works. This used to work with JUCE 5.3. Can i do something about this or does this need a JUCE fix? Looks like this is broken now in the AU version.

At which JUCE commit did things break? I believe this will narrow things down

No sure. I’m using the latest release. The previous latest version worked AFAIK. I had this in production and no reports.

edit: After adding the parameter groups.

I have found out that all plugin-formats are affected. JUCE_FORCE_USE_LEGACY_PARAM_IDS breaks automation with the latest JUCE 5.4 at least for my plugins. Tested on OSX. Any help / fix / work around is welcome.

@kunz What are you using as groupID when creating the AudioProcessorParameterGroup instances?

Sorry for the mistake. I didn’t use parameter groups. I think JUCE_FORCE_USE_LEGACY_PARAM_IDS with automation is broken on OSX since parameter groups are added to the code. Can someone reproduce this?

I use JUCE_FORCE_USE_LEGACY_PARAM_IDS as well as JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE and automation works fine for me with the latest tip code (used Logic Pro X to confirm). However I am not using AudioProcessorValueTreeState, but my own Parameter classes and ways to attach Params to a ValueTree. Maybe this helps to narrow down the code region where a problem might be happening.

1 Like

Thanks for the answer. If i disable JUCE_FORCE_USE_LEGACY_PARAM_IDS, parameter handling works. That makes me think that it could be a JUCE bug. I don’t have any “known” special implementations :slight_smile: It happens only in OSX.

When i debug, parameters aren’t attached and do not notify any changes by the host automation. I will make some more tests. Maybe i also have time to try this with the JUCE example synth plugin.

The wrapper code is hard to understand and i’m not sure how automation notifications by the host should happen and why they could fail.

So, are you saying that if you enable JUCE_FORCE_USE_LEGACY_PARAM_IDS and do

treeState = new AudioProcessorValueTreeState(*this, nullptr);
auto parameter = treeState->createAndAddParameter(paramName, text, String(), { fromValue, toValue }, defaultValue, valueToTextFunction, nullptr, isMetaParam);
treeState->state = ValueTree("MyValueTree");

before the “Added plug-in parameter groups” commit (note, none of the newer APVTS stuff is available) and save some automation, then checkout that commit, then rebuild, then the automation isn’t picked up by the plug-in?

Hi Tom, thanks for your help. I didn’t test the compatibility with older sessions that include automation.

I can’t get automation (new ones) to work on OSX with JUCE 5.4 when JUCE_FORCE_USE_LEGACY_PARAM_IDS is enabled.

The problem is that the plugin does not get any automation notifications. When i disable JUCE_FORCE_USE_LEGACY_PARAM_IDS all works ok, but i need that switch to stay compatible.

This used to work with 5.3.

I suggest that you use git bisect to find the exact commit in JUCE that broke things for you. Right now you have kind people (some from JUCE team some not) trying to help you by guessing in the dark but the most helpful info to pinpoint the problem is if you can say “before commit X it works and since that commit it doesn’t”. This will reduce the search-space of relevant code-changes that caused the bug significantly.

(third time I’m suggesting it in this thread actually, sorry for being a PITA and I won’t suggest again)

I see your point and thanks for your help. There are 50 commits since the last release. I don’t have that much time at the moment. I will try to reproduce with the juce demo plugin as a next step.

I really expect that someone from the JUCE team will help me if i can deliver some sample code that shows the issue.

edit: bisect looks nice, but i think it takes some iterations when you have that much commits.

Yes, we will certainly help you, but the more information we are given the better.

We have a backlog of things that need to be done. If the difficulty of a task is immediately easy to estimate then we can often start looking into it straight away. If the problem is less well specified then we have to assume it will take much longer and it will consume at least the time needed to investigate more throughly.

However, since this particular bug seems like it might affect a decent number of people (especially longer-term JUCE users) it’s been bumped up in priority.

git bisect start
git bisect good 5.3.0
git bisect bad 5.4.0
git bisect run xcodebuild -project ~/Development/JUCE-examples/AudioPluginDemo/Builds/MacOSX/AudioPluginDemo.xcodeproj && ! auval -v aumf Aiiv Manu | grep "WARNING: Cannot Retrieve information for published parameter"

About 10 automatic recompiles later:

e05a1549f226b2ae4567551508f1082c8d220058 is the first bad commit
commit e05a1549f226b2ae4567551508f1082c8d220058
Author: hogliux <>
Date:   Wed Apr 4 11:02:43 2018 +0100

    Re-worked plug-in wrappers to all use new parameter system via LegacyAudioParameter wrapper class

:040000 040000 8a97a29d4d3b8318592395dc8678f79b74d3dc4d 0dbb6ebea0a54ea0cbe4e0bfad069cf3f77f670e M	extras
:040000 040000 966226828de1ee18dd3672bfa124a9255867b648 dbc8eb66ea58aa4d699a9f72579947f879f784b2 M	modules
bisect run success

Thanks for looking into it. I will try to give more information next time.

1 Like

What version of Xcode is this? Without the -UseModernBuildSystem=NO parameter Xcode 10 can’t be trusted to recompile JUCE sources when they change (probably due to not properly supporting JUCE’s #include "something.cpp" stuff) sometimes resulting in misleading bisect results.

We’re grateful for any bug reports! I’m just giving people a hint that (in general) the narrower the problem the quicker it’ll be fixed.

Yes, this is on an Xcode 9 only machine. I initially forgot about Xcode 10, got some nonsense, then just switched to a different computer.


1 Like

Thanks a lot for the fast fix. It works!

1 Like