getText not called on AU, while using legacy parameters

Audio Plugins
1

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!

2

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?

3

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

4

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?

5

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;
    }

   ......
}
6

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()?

7

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!

8

Can you work out why usingManagedParameters is false?

9

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.

10

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?

11

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.