Suggestion: AudioProcessorValueTreeState AudioProcessorParameter getUnnormalizedValue

Audio Plugins
1

Hi there,

when using the AudioProcessorParameter in the very cool AudioProcessorValueTreeState, I have the callback void parameterChanged (const String &parameterID, float newValue) with the unnormalized value.
But when I call the AudioProcessorParameter::getValue(), I get the normalized value and I have to convert the value back to the unnormalized form. It would be great to have a method to access the value returning the same as the callback.
I had to learn that painfully, when I had a slightly different conversion after calling getValue() :frowning:

Thanks for considering…

2

Further information:
In AudioProcessorValueTreeState::Parameter i added:

float getUnnormalizedValue() const override { return range.snapToLegalValue (value); }

And to make it usable in AudioProcessorParameter:

virtual float getUnnormalizedValue() const { return getValue(); }

A pure virtual would be preferred, but then everybody would need to adapt their AudioProcessorParameter implementations. And as the base class is not aware of any range, it is correct to return the same as getValue.

My use case: I call it in AudioProcessor::prepareToPlay and after a AudioProcessor::setStateInformation call, so threading issues shouldn’t be an issue.

3

Hi @jules, can you please give a short statement, if this may come, or if there are problems I missed.
I’m using it locally already…
Cheers

4

bump
btw. do you care for pull requests? I added a disclaimer in the last one wich should avoid copyright issues…

5

Thanks! Pull requests are a good way to show us what changes you’re suggesting, though we need to clarify with our lawyers what the situation is as far as copyright waivers before we can openly accept them.

6

bump the original question:
Wouldn’t it be good to have a AudioProcessorValueTreeState::Parameter::getUnnormalizedValue() to return the same as AudioProcessorValueTreeState::Listener::parameterChanged()?
parameterChanged() returns the parameter normalized to the range while AudioProcessorValueTreeState::Parameter::getValue() is normalized to 0to1.
When I call getValue on a parameter, I usually have no access to range, so I cannot re-convert the 0to1 value.
Like I wrote before:

P.S. maybe somebody finds a better name…?

Thanks for feedback…

7

+1 for this request. I’ve run into a few examples where a virtual getUnormalizedValueFunction as suggested would be really useful in the AudioProcessorParameter class.

8

Is anyone able to answer whether this request might be followed up / added to the develop repo?

1 Like
9

@jules: can you please give a sign, if this is a safe approach, or are there problems reading the values directly from the AudioProcessorValueTreeState?
I use it as a replacement for this kind:
https://github.com/ffAudio/ffTapeDelay/blob/master/Source/PluginProcessor.cpp#L135

But it would be

  1. more efficient, if I don’t have to do the lookup for the range
  2. way more readable code
  3. maybe the perfect place to make it thread safe: if the range changes and the value is about to change, I get complete wrong results (yes, the parameter range is unlikely to change, but it serves as example)…

Thanks for your feedback

2 Likes
10

No objections to that approach in AudioProcessorValueTreeState, but would need to give it some thought before adding it to the AudioProcessorParameter base class. At face value it seems pretty sensible though.

In things like Equator what we actually tend to do, IIRC, is that the audio engine itself doesn’t look directly at the state, it just has raw parameters that get updated by various callbacks when the value tree changes.

11

Great, thanks for the feedback. Please let me know when you have decided, so I can remove the changes from my repo.

Ok, I understand. That’s harder to maintain, but reduces the possibility that two threads access the variable at the same time… Will have to think about it.

12

Also a helpful class that was something we created in Tracktion is the CachedValue class, which is designed for exactly this purpose of holding a typed cached copy of a ValueTree value.