Question on AudioProcessorValueTreeState::Listener documentation

General JUCE discussion
1

In AudioProcessorValueTreeState::Listener's parameterChanged(const String& parameterID, float newValue) documentation, it says the following:

“Within this call, retrieving the value of the parameter that has changed via the getRawParameterValue() or getParameter() methods is not guaranteed to return the up-to-date value. If you need this you should instead use the newValue parameter.”

Looking through the code, it seems like the value passed in for newValue is always pulled from the value that both getParameter() and getRawParameterValue() would return. Am I missing something?

2

Did you ever figure this out? I’m reading through the documentation and have the same question… What is the correct way to get up-to-date values?

3

We never hit / found any issue with polling the parameter value (or any other parameter value, for e.g. linked parameters). That said, the documentation still says not to do it, looks like.

4

The Listener lists have an arbitrary order depending on how they were set up.
Depending on how the code was set up, some internal listeners might not have been notified yet.
I think that is the reason for that comment.

Especially if you get a listener callback for parameter A, there could be an update for parameter B in the pipeline that makes the result of getRawParameterValue ("B") outdated within the callback of parameter A.

5

Hm, I don’t think the order of the listeners would matter here?

Anytime parameterChanged() is called, it’s from AudioProcessorValueTreeState::ParameterAdapter::parameterValueChanged(), which passes the unnormalisedValue member. That’s the same value that is fetched in AudioProcessorValueTreeState::getRawParameterValue(), which is why I find the comment confusing.

So it seems the only thing that could happen is getRawParameterValue() would return a more up-to-date version of the parameter (taking multithreading into account), which would then be set in the next parameterChanged() callback anyways. Unless I’m being dense about something (which is entirely likely :wink: )

You’re right about the linked parameter case, though using your example, as long as I have the callback for parameter B also check the value of parameter A, it shouldn’t be an issue since the last queued parameter will ensure both values are correct.