It appears that the commit 1398ce6290a82fe764b8593724703f3fa4f6d34a on the develop branch introduces an issue with how parameters are displayed in Logic’s generic parameter editor.
With the commit, the parameters are displayed normalised with too many digits to properly show in the UI. This makes the generic editor unusable.
I can’t find that commit ID… Also, do you mean this view? It looks normal to me.
Sorry, I messed up the commit hash. The correct one is 57421a90419f69db9218073fc7763829f011e3e6.
And the problem is that the values in the textbox are unformatted. Before that commit, they have been formatted correctly.
How are you adding your parameters? The number of decimal places displayed is based on the interval of the NormalisableRange of your parameter e.g. an interval of 0.1 will display the parameters with 1 d.p.
Have you performed a before/after comparison? Before it would show -2.3dB for gain, now it shows something like 0.87034153. This is not just about the number of decimal places, that is just a symptom of the formatting (including scaling and adding the suffix) getting lost.
This happens independently of how I add the parameter. As soon as I add any formatting relevant information, it is ignored. And that is not only true for the generic editor but also for all things automation related.
Can you post an example which demonstrates the problem? If I change the AudioPluginDemo processor constructor to add this gain parameter:
std::make_unique<AudioParameterFloat> ("gain", "Gain", NormalisableRange<float> (-60.0f, 100.0f, 1.0f), 0.0f, "dB",
AudioProcessorParameter::genericParameter,
[] (float value, int max) { return String (value, max) + " dB"; },
[] (const String& text) { return text.getDoubleValue(); }),
then it displays correctly in Logic’s controls view.
I have not tried custom formatters, because before it worked without using them and they are only providing redundancy. My point is not that there is no workaround, there clearly is, but that there is a behavioural regression that should either be fixed or at the very least be documented and reasonably motivated.
Here is the most simple parameter construction that already shows the problem. It doesn’t have a suffix, but the scaling and formatting is messed up:
std::make_unique<AudioParameterFloat>("test", "Test", -12.0,24.0, 0.0 )
This is a result of a longer journey of changing back and forth of the behaviour of the String (double, numDecimalPlaces) constructor, as I understand it.
It started with this feature request:
and concluded in the behaviour being changed a few times, until it was thought all parties are happy:
Seems to be difficult to create a coherent solution with full backward compatibility. It probably needs to be deliberately broken, so every user has to choose the behaviour that suits his use case.
So, are you saying that because there is a problem with the design of the String class, that there won’t be any default formatters for audio parameters anymore? That sounds unlikely.
Indeed, I had my money on the wrong horse. I did some digging, and the GenericAudioProcessor calls:
void updateTextDisplay()
{
valueLabel.setText (getParameter().getCurrentValueAsText(), dontSendNotification);
}
while in getCurrentValueAsText() the LecacyAudioParameter called:
return processor->getParameterText (parameterIndex);
the new parameters does no formatting at all. They just pipe the float value through the default String() method.
That means, you cannot change the display from the AudioProcessorParameters, if I am not mistaken…
OK, this commit should revert the display behaviour to using 2 decimal places when the simple AudioParameterFloat constructor is used.
Can you clarify what you mean by the scaling and suffix formatting being affected? It would be useful if you could post some code which demonstrates the behaviour change. And also, just to be clear, when you say that this issue is present in “Logic’s generic parameter editor” do you mean the editor which I posted a screenshot of above which is displayed when you select the “Controls” view in the Logic AU editor window, or do you mean JUCE’s GenericAudioProcessorEditor?
Oh dear, I completely missed that. Sorry, I might have led the conversation into the wrong direction…
And yes, the JUCE GenericAudioProcessorEditor uses the correct parameter’s valueToText function:
strange, I must have misinterpreted the code…
I’ll better leave it here
text-number conversion for GUI representation or for data serialisation are two complete different things
so we have to fix the data-model for better GUI representation…??
