V6.0.8 Issue: AudioProcessorParameter::getName() no longer get called on setValueNotifyingHost()

Audio Plugins
1

Spotted this issue after updating to v6.0.8. Before v6.0.8, AudioProcessorParameter::getName() is called right after every AudioProcessorParameter::setValueNotifyingHost(), but it no longer get called.

Found this issue in our AU plugin in Logic Pro, haven’t tested vst/vst3 and other formats yet.

After a little digging with AU, I found after setValueNotifyingHost() calls JuceAU::sendAUEvent(), it used to trigger JuceAU::GetParameterInfo(). While in 6.0.8, GetParameterInfo() is no longer get triggered after JuceAU::sendAUEvent(). Hope this helps.

Please advise, thanks.

2

GetParameterInfo is called in response to a host request for the parameter information. That is, the host decides when to call it, rather than the plugin. Have you tested the old and new versions of the plugin in exactly the same host, or is it possible that you’re testing the new version of the plugin in a different host with slightly different behaviour?

The only guarantee that JUCE makes about getName is that it will be called when some entity (probably the host) asks for the parameter name. JUCE definitely does not guarantee that getName will always be called after a call to setValueNotifyingHost, so you should not rely on this behaviour in your plugins.

If you can supply more information about your use-case we may be able to advise on an alternative structuring of your plugin.

3

Yes, I’ve tested both the old and new versions side-by-side in exactly the same host. Once switched back to 6.0.7, getName() gets called consistently, while switching to 6.0.8, it only gets called on parameter initializations and never got called after. And I did the test on 2 different Macs, got the same result. That’s why I reckon there must be some changes in the new version that causes the change of behavior.

The reason why I need that to work is that my plugin is a modular synth, user can add/remove modules at any time, each module has different parameters, so every time a module is added or removed, the plugin needs to rename the parameters properly so that the host reflects the name changes.

The way it works right now is:

  1. Creating my own subclass of AudioParameterFloat, adding a String member variable, and overriding the getName function to return the stored name.

  2. Initializing enough amount of parameters in the constructor of my AudioProcessor, with their names set to empty strings, so the host wouldn’t display them in the automation menus.

  3. When a new module is added, updating the name stored in my subclass of AudioParameterFloat, followed by a setValueNotifyingHost.

  4. The host is now aware of the change so the parameters in the automation menu get updated.

This is how I created the parameters.

AudioProcessorValueTreeState::ParameterLayout SBoardAudioProcessor::createParams()
{
    AudioProcessorValueTreeState::ParameterLayout layout;
    for (int i=0; i < MAX_NUM_PARAMS; ++i)
    {
        layout.add(std::make_unique<SBAudioParameterFloat>(String(i), "", NormalisableRange<float> (0.f, 1.f), 0.f));
    }
    layout.add(std::make_unique<SBAudioParameterFloat>("master_bypass", "master_bypass", 0.f, 1.f, 0.f));
    return layout;
}

And the name update:

//parent is my AudioProcessor

SBAudioParameterFloat* target = static_cast<SBAudioParameterFloat*>(parent.getParameters()[i]);
// displayName is the member String variable in my custom subclass to store the name
target->displayName = vt.getType().toString() + " - " + param.getType().toString();
// other configurations
target->beginChangeGesture();
target->setValueNotifyingHost(target->to0And1(param.getProperty(PARAM_CURRENT_VALUE)));
target->endChangeGesture();

Not sure if it’s related, but I’ve been using APVTS to manage the parameters.

Hope this explains the issue and what I’m trying to achieve, please advise, thanks.

4

I think calling updateHostDisplay() would be a safer way to do what you’re after.

5

I do call updateHostDisplay() after the name change, this call has always been in the code, so I don’t think it’s related to the issue. Thanks for the heads-up anyway.

6

I think the call to updateHostDisplay is probably the issue. This now takes an argument explaining the nature of the change to the AudioProcessor. To update the parameter labels, you should pass ChangeDetails{}.withParameterInfoChanged (true) to updateHostDisplay.

2 Likes
7

That seems to be like quite a breaking change, perhaps the default version of ChangeDetails can assign ‘true’ for all the options to be compatible with old code?

1 Like
8

It works after passing the change details in, thanks for the help. And I agree with eyalamir, it is quite a change, a default “true” will help, and maybe also add this change into the release note so that others will be aware of it.

1 Like
9

Glad that works. I think you’re right this is a breaking change, so I’ve updated updateHostDisplay to preserve the old behaviour by default:

It’s still a good idea to make your changes as specific as possible though, so I’d recommend keeping ChangeDetails{}.withParameterInfoChanged (true) in this situation.

2 Likes