Showing a label e.g. Hz, dB using AudioParameterFloat?

I remember when using the AudioProcessorValueTreeState parameter system it’s easy to show labels.

How do you do this for sliders using the AudioProcessorFloat way?

Many thanks,

You can easily do it in the Slider class: Slider::setTextValueSuffix (const String& suffix)

Then you can eventually generalize using the AudioProcessorParameter’s Label, at least the documentation suggests the label might be used for that purpose:

slider->setTextValueSuffix (parameter->getLabel());

Hope that helps


Although my usual procedure is to create a AudioParameterFloat and then use addParameter() in the the PluginProcessor constructor.

Looking at the AudioParameterFloat there seems to be no way to conveniently set the label?

(Apart from awkward dynamic cast to AudioProcessorParameterWithID and then set label??)

You are right, the super class of AudioParameterFloat, AudioProcessorParameterWithID implements getLabel(), but setLabel is not supported and I can’t find a constructor parameter either.
@juce: is this missing? forgotten, or no longer wanted?

So if there was a setLabel method, I think you can do like:

addParameter (AudioParameterFloat* myFloat = new AudioParameterFloat ("myID", "myName", etc);
myFloat->setLabel (" Hz");
1 Like

Is there any way of adding a ‘units’ label to a parameter, like “Hz” or “ms”, in Juce 7?

I want to add something like this…

		AudioParameterFloatAttributes attrib;
~		paraTree.createAndAddParameter(std::make_unique<AudioParameterFloat>(parName, dispName, norm, defaultVal, attrib));

But that doesn’t seem to work. Can it be done?
This code always sets label to “” if I do the above init.

	AudioProcessorParameterWithID* par = paraTree.getParameter(name);
      // ...Check valid...
	label = par->getLabel();

So that can’t be right, can it?

Looking through the sources, getLabel() is only used by the wrapper to forward it to the host. No juce component bothers about the label.
Instead there is the valueFromText and textFromValue lambdas, which turn into the getText and getValueFromText in AudioProcessorParameter.
I wonder what happens if there is that lambda provided AND a label?

TBH I would leave the label alone and add the lambdas like:

RangedAudioParameterAttributes::StringFromValue makeStringFromValue (const juce::String& unit)
    return [unit](float value, int) { return juce::String (value) + " " + unit; };
RangedAudioParameterAttributes::ValueFromString makeValueFromString()
    return [](const juce::String& text) { return text.getFloatValue(); };

You could add a checking of the unit, but I thought it’s not necessary.

Btw. the doxygen got confused, it mixed up the template parameter Value with juce::Value

1 Like

withLabel returns a copy of the attributes with the change applied, so this won’t have any effect (the copy is immediately discarded).

AudioParameterFloatAttributes attrib;

You should probably write it like this instead:

const auto attrib = AudioParameterFloatAttributes().withLabel("Hz");

Please add [[ nodiscard ]] to these kind of functions.

These functions are already marked nodiscard.

1 Like

Brilliant! Thanks for the help.

You should use compiler flags to make errors out of warnings. You shouldn’t have been able to even compile this with the [[ nodiscard ]] attribute.

1 Like

In the main branch there is JUCE_NODISCARD

And in pre-C++17 this is removed, because [[nodiscard]] is not available yet.

That’s why it compiles…

I’m currently using C++20 in VS2022 - I see the warning, I also see an explanation can be added in #20 C++ attribute: nodiscard (since C++17) -

I used to get hundreds of warnings from the Juce code with a clean build on Windows, so I turned warning as errors off, unfortunately.
It’s all good in Juceland now though - All my warnings are now just my own code! :grin::rofl::roll_eyes:
Thanks again.