getText not called on AU, while using legacy parameters

Hi guys,
I’m porting some old plugins from JUCE 3.2 to JUCE 5.4.1
I enabled both JUCE_FORCE_USE_LEGACY_PARAM_IDS and _LEGACY_PARAMETER_AUTOMATION_TYPE, but I noticed that the AU version of the plugin is displaying 0…1 values instead of the normalized one. I have a wrapper for my parameters and, debugging, I noticed that getText is not get called at all when you move the parameter from the params list.

Anybody else experienced that?
Thanks!

If your wrapper is using overridden parameter methods from AudioProcessor (e.g. AudioProcessor::getParameter (int) and not adding parameters using AudioProcessor::addParameter then there is no way of accessing the getText functionality. The AudioProcessor class provides AudioProcessor::getParameterText (int), which has different behaviour to AudioProcessorParameter::getText (float, int). You can see how the mapping between the (now deprecated) AudioProcessor methods and the AudioProcessorParameter class is done here:

That being said, it feels like I may be misinterpreting your problem. By “instead of the normalized one” do you actually mean the non-normalised one (which would be a range other than 0…1)? Is this something that used to work in JUCE 3.2?

Hi tom,

In my wrapper I’m deriving from AudioProcessorParameterWithID (while on 3.2 I were doing the same with AudioProcessorParameter) and overriding the methods I need, including getText. The parameter is added via addParameter, and so it was on 3.2. Always worked and works on JUCE 5 too, but getText looks like is not allowed when you use legacy paramters (there’s an assert on those methods in the LegacyParameter class).

Thanks

If you’re deriving from AudioProcessorParameterWithID then I don’t know what’s going on. You won’t be using the LegacyParameters wrapper.

I’ve just tried

#define JUCE_FORCE_USE_LEGACY_PARAM_IDS 1
#define JUCE_LEGACY_PARAMETER_AUTOMATION_TYPE 1

with a simple class derived from AudioProcessorParameterWithID and everything is working as expected with getText being called.

Can you provide any other info?

What happens if you stick a debugger in ComponentResult GetProperty in juce_AU_wrapper.mm? Are you hitting the kAudioUnitProperty_ParameterStringFromValue case?

Hi Tom,

yes, I’m hitting kAudioUnitProperty_ParameterStringFromValue and if (LegacyAudioParameter::isLegacy (param))

My parameter wrapper is simple:

class newFloatParameter : public AudioProcessorParameterWithID
{
  public:
    newFloatParameter(const String& parameterID, const String& paramName,   NormalisableRange<float> range, float defaultParameterValue, const String& paramUnit, Category category = AudioProcessorParameter::genericParameter)
    : AudioProcessorParameterWithID (parameterID, paramName, paramUnit, category)

    ...

    String getText(float value, int maximumStringLength) const override
    {
        return String(myRange.convertFrom0to1(value), 1) + " " + unitString;
    }

   ......
}

So, as far as I can see, when LegacyAudioParametersWrapper::update is called (in void addParameters() in juce_AU_wrapper) then we want usingManagedParameters to be true, otherwise we’ll add legacy parameters.

Have you overridden AudioProcessor::getNumParameters()?

No. To migrate old plugins I use the files created by a new Projucer project, then I basically work as I’m making a plugin from scratch. getNumParameters is marked as deprecated, thus not used in my projects.

Thanks again, Tom!

Can you work out why usingManagedParameters is false?

In LegacyAudioParametersWrapper::update, we have:

usingManagedParameters = (audioProcessor.getParameters().size() == numParameters) && (! legacyParamIDs);

getParameters().size() is the same as numParameters, so the condition is true; legacyParamsIDs is true (because we set the forcing flag to 1), but negated. That’s why usingManagedParameters is false.

Ah, I was working from the current master - I didn’t spot that you were not using the most recent version of the code.

Do things work if you update?

I were writing the same. I noticed on your current master that the usingManageParameters line has changed since 5.4.1. I use to work exclusively with the release version and since this wasn’t reported in the changelog, I didn’t update.