ParameterAttachment::resetToDefaultValue()

Feature Requests
1

The current and only possible way to reset a parameter to it’s default value is like this:

auto* freqParam = apvts->getParameter(...);
auto defaultValue = freqParam->getDefaultValue(); //this is a normalized value
freqParamAttachment.setValueAsCompleteGesture( freqParam->convertFrom0to1(defaultValue);

This is annoying because:

  • AudioProcessorParameter::getDefaultValue() returns a normalized value
  • ParameterAttachment::setValueAsCompleteGesture() wants a De-normalized value
  • ParameterAttachment::setValueAsCompleteGesture() internally normalizes the de-normalized value that is passed in.

All that needs to be added is:

void ParameterAttachment::resetToDefaultValue()
{
    beginGesture();
    parameter.setValueNotifyingHost(parameter.getDefaultValue());
    endGesture();
}

I am currently using Component::mouseDoubleClick as the way that I tell the parameter to reset to the default value.

AudioParameterFloat getDefaultValue()
2

I ran into something similar today…Outside of the apvts, it’s pretty convoluted to set an AudioParameterFloat back to its default. getDefaultValue is private, so this was the only route I could see:

param->setValueNotifyingHost (dynamic_cast<juce::RangedAudioParameter*> (param->getDefaultValue()));

vs. an ergonomic API like

param->setToDefaultValue()

My context: meta parameters need to be able to change other parameters.

Related:

Parameters still feel due for a round of auditing/cleanup, the API is a bit all over the place and the docs neglect to specify what’s normalized, what’s not (for example getDefaultValue returns normalized, setValueNotifyingHost expects normalized, neither are explicitly documented).

3

Yes, I agree. I just added this function to my code:

void ParamHelpers::setToDefault(AudioProcessorParameter& param)
{
    param.setValueNotifyingHost(param.getDefaultValue());
}

Used like:

ParamHelpers::setToDefault(param);
1 Like