AudioProcessorValueTreeState raw value pointer thread-safety

[CrushedPixel]

Are the pointers returned by AudioProcessorValueTreeState::getRawParameterValue implemented to be thread-safe? I know that it’s realtime-safe to access them from the Audio Thread, but is it thread-safe if I modify these values from the Message Thread using AudioProcessorValueTreeState::getParameter().setValue()?

[t0m]

Technically, no; they’re not thread safe.

However, unless you’re running on some very unusual hardware, there’s no need to panic.

Loads more info here:

AudioParameter thread safety

I am looking at the AudioParameterFloat and AudioParameterInt classes in JUCE and I fail to see how they are thread safe. It appears that setValue sets the value and the audio thread gets the value without any sort of fifo or thread safety despite in their base class AudioProcessorParameter it says that getValue and setValue should be “thread aware”. Is it safe to use these classes and set them on the UI thread and get them on the Processing thread as is done in the AudioPlugin Examples?

[CrushedPixel]

Hm. I’m kind of with @Mayae on this issue, as I’ve spent the past week completely re-writing my plug-in’s internals to thread-safely and realtime-safely (that one was annoying) access and modify the internal data structure from both the Message and Audio Thread, only to find out that the other half of my plug-in (which uses the APVTS) doesn’t give a damn about it.

Would it be too difficult to change the ParameterAdapter::unnormalisedValue's type from float to atomic<float>? If we’re going the “let’s assume we’re running on usual hardware” route, these should be realtime-safe (as in lock-free).

If atomic<float> is not lock-free on some platform, it wouldn’t be realtime-safe anymore, but in that case not having it atomic would probably break thread-safety completely, so it’s better in any case.

[CrushedPixel]

I realize that this would change the interface of getRawParameterValue to return an atomic<float> *, but for most use cases, client code wouldn’t even need to be updated, since atomic<float> is implicitly convertible to float and exposes an assignment operator=(float)

[t0m]

Adding a thread safe way of accessing the raw parameter values is on our todo list. As Fabian said in the other thread, we’re not arguing against the use of atomics.

but for most use cases

… only if you’re using auto or not storing the parameter value at all.

There are a handful of similar breaking changes we want to make, which we’ll do sometime shortly after the next JUCE release. This gives people the maximum amount of time to adapt their code.

[CrushedPixel]

Thanks, that’s great to hear. I really appreciate that you’re listening to your user base