Reaper: Why are AU Parameters only displayed as normalised values? (Can be reproduced with JUCE demo plugin)

Don’t know if it has been discussed here before, didn’t find any topic on it.

When using AU plugins in Reaper, only the normalized parameter values are shown to the user when automating or switching to the generic parameter view. For an example this is what the JUCE DSPModulePluginDemo looks like as VST3

And this is what it looks like as AU

Seems like all the value to text stuff doesn’t work here. However, looking at a non JUCE AU, I this seems to work, so it doesn’t seem like a general Reaper/AU issue…

Loading the same JUCE example plugin as AU in a different non-Apple AU host, e.g. in Ableton Live (used Live 9 here) shows us that that the value to text translations works here

So I wonder what’s wrong here that it doesn’t work in Reaper? Is it a Reaper issue or a JUCE issue? Any hints would be appreciated!

I don’t know the source of the problem, but I can verify that I’m seeing the same thing too (comparing my JUCE plug-ins in Reaper vs Live).

Glad to hear that I’m not the only one facing this :wink:

Does someone of the JUCE team have an idea where to search for the source of this? I really don’t know if it’s a Reaper or JUCE fail, but as I see other AUs working in Reaper, I tend to believe that this is a JUCE error…

This post (with no responses) is talking about the same issue too:

Also, for what it’s worth: I just checked in Reaper, and for an AudioParameterChoice parameter, the stringFromIndex lambda is in fact used in the generic UI value display - so the lambdas aren’t universally ignored.

So far, it’s just the AudioParameterFloat that I’m seeing displayed as normalized 0-1 values (haven’t tried AudioParameterBool or the others yet).

Note that this display issue with AudioParameterFloat happens even if the parameter was initialized with a NormalisableRange other than 0-1. So in the Reaper UI, not only does the stringFromValue lambda go unused, but the value displayed is 0-1 normalized, even if it was given a range of, say, 0-100.

So for some reason, it seems like Reaper’s generic UI is displaying what it gets back from AudioProcessorParameter::getValue (which, in turn, calls RangedAudioParameter::convertTo0to1). Probably something going on in the AU wrapper?

1 Like

Experienced the exact same behaviour.

I’ll bump this since I see this too

Rail

I’ve looked into this a bit, and at the moment it looks like this issue is on the hosting side.

I expect that the AU plugins which appear to work in REAPER are exposing the non-normalised parameter ranges to the host. However, JUCE AU plugins only expose normalised parameter values to the host for non-discrete parameters. This is by design, and changing this behaviour is not really viable, as it would likely require a change along the lines of requiring RangedAudioParameter to be used everywhere that plain AudioProcessorParameters are allowed at the moment. Such a change would break most users’ plugin projects.

Luckily, the AU header provides a pair of properties, kAudioUnitProperty_ParameterStringFromValue and kAudioUnitProperty_ParameterValueFromString which allow parameter values to be converted to strings and back. The docs for ParameterStringFromValue state:

This property is used with parameters that are marked with the kAudioUnitParameterFlag_HasName parameter info flag. This indicates that some (or all) of the values represented by the parameter can and should be represented by a special display string.

ParameterStringFromValue… states to the host that if it is displaying those parameter’s values, they should request a name any time any value of the parameter is set when displaying that parameter.

Further on in the AU header, we find this:

enum {
	kAudioUnitParameterFlag_HasName = kAudioUnitParameterFlag_ValuesHaveStrings
};

In the JUCE AU wrapper, we mark all parameters with the ValuesHaveStrings flag. If I’m interpreting the docs correctly, the host should use StringFromValue to translate values of parameters marked with this flag. In Live, breakpoints placed in the StringFromValue branches of GetProperty and GetPropertyInfo are hit when modifying parameters through the generic display shown in @PluginPenguin’s initial post. However, REAPER doesn’t seem to do this (breakpoints in the same locations are never hit).

At the moment I think this is a bug in REAPER, so I’ve created a bug report thread on the official forum.

4 Likes

Thank you once again for taking the time for an in-depth look at it, documenting your findings here in a detailed way and taking care of a proper bug report. I see this happening frequently lately and I really appreciate that :slightly_smiling_face:

4 Likes