Automated parameters are not recalled correctly in Logic/GarageBand

[dariop]

Hi,

I’ve just updated my plugin (old is 1.0, new is 1.1), but we’ve just found a catastrophic bug that I can’t wrap my head around!!

Someone whos been using version 1.0, who has projects with automation lanes and whatnot, will load an old project with new version 1.1, and many of the audio parameter automations will be SWAPPED/JUMBLED. eg. an automation lane for parameter “pitch”, now gets read as the automation lane for parameter 8 “volume”.

This basically invalidates any previous save. I thought the point of the value tree/apvts is that this shouldnt happen?

This is how I’m retrieving and setting the state. Does anyone know what I’m doing wrong??
Should I be using xml state instead of a MemoryOutputStream?

void AmigoAudioProcessor::getStateInformation (juce::MemoryBlock& destData)
{
    juce::MemoryOutputStream stream(destData, false);
    apvts.state.writeToStream(stream);
}

void AmigoAudioProcessor::setStateInformation (const void* data, int sizeInBytes)
{
    juce::ValueTree tree = juce::ValueTree::readFromData(data, sizeInBytes);
    
    if(tree.isValid())
    {
        apvts.replaceState(tree);
        //Do some stuff ..
    }
}

So far this has only happend on certain daws, but I am investigating further to see if its a vst3/au issue.

Would highly appreciate any ideas.

Cheers,
Dario

[reuk]

This sounds similar to a known bug in Logic Pro where it restores automation data using parameter indices instead of parameter identifiers. There’s more information in this thread:

Adding parameters post launch to a plugin?

We’ve now heard back from Apple on this topic. This is a known limitation of Logic, but not one that is likely to be fixed. We’ll add some sort of workaround to JUCE, but this will need some careful thought to ensure that the parameter system remains intuitive, maintainable, and consistent between plugin formats. I’ll update this thread once we’ve made some progress.

You’d be affected by this bug if you added or removed parameters between versions 1.0 and 1.1, and the new parameters don’t have a higher “version hint” than the old parameters.

Please can you provide the following information:

• Which DAWs exhibit the broken behaviour?
• Have you added or removed parameters between version 1.0 and 1.1?
• If so, are you setting version hints correctly on all parameters? Parameters added in later versions should always have a greater version hint than parameters added in earlier versions.

[dariop]

Hi, thanks for the response.

I imagined it was something along these lines.
Yes its only logic that I’ve found this on.

Yes, I have added 3 new parameters, and added them to the end of the the parameter list in my createParamterLayout() function, so i thought there wouldnt be any jumbling problems, but i guess i was naive.

I thought it was something to do with version hints, but I’m not sure how to use them correctly.

Am I right in saying that old paramters should be created with a juce::ParameterID{id, 1}
And new parameters should be created with a juce::ParameterID{id, 2}?

Cheers

[reuk]

@dariop

Am I right in saying that old paramters should be created with a juce::ParameterID{id, 1}
And new parameters should be created with a juce::ParameterID{id, 2}?

Exactly that, yes. If you add more parameters in version 1.2, then you’d use a hint of 3 for those, and so on.

[dariop]

Amazing, thank you so much!

[daniel]

Awesome, sorry if I hijack:
Does that mean that the parameters are kinda sorted by the version hint? Couldn’t I just use incremental version hints in the first place?

This would even allow re-ordering of parameters…

I am using setParameterTree in the constructor and was wondering how to make sure that adding parameters in the middle of the tree doen’t screw up the autiomations…

[reuk]

@daniel

Does that mean that the parameters are kinda sorted by the version hint? Couldn’t I just use incremental version hints in the first place?

You could, but then you’re back to effectively identifying parameters by index instead of ID, VST2-style.
Note that the version hints are only taken into account in AU plugins, they’re currently ignored in other plugin formats. The parameter order is also only relevant in Logic and GarageBand. Other AU hosts implement parameter automation as specified in the AU docs, using the parameter identifier.

@daniel

I am using setParameterTree in the constructor and was wondering how to make sure that adding parameters in the middle of the tree doen’t screw up the autiomations…

I believe (though it’s a while since I have worked on this area so I could be wrong) that in AUv2 it’s possible to add parameters to the middle of the tree without breaking automation in Logic/GarageBand, as long as the parameter hints for the new parameters are higher than the version hints for the old parameters. From memory this may not work in AUv3.

[daniel]

Ok cool. It adds an option, which might or might not work consistently at least.

I am working on a soon illegal tool, where the user can supply parameters, so it should be as fool proof as possible

[reuk]

I updated the thread title to make it clear that this isn’t an APVTS bug, hope that’s alright.