Standard approach to maintaining shared State with Processor and Editor(s)

Audio Plugins
1

Hey guys,

I just started learning JUCE recently to help a friend implement a simple VST plugin for MIDI related re-mapping and visualization.

First off, in case it doesn’t get mentioned enough, great job on the framework itself. I found it a breeze to get setup and running basic plugin functionality with in my DAW. I was actually surprised how straight forward it was.

Through the tutorials, docs and community, I am slowly coming to grips with the power provided by the framework and appreciating it more and more. To all those who have contributed directly, or supplemented it by being active participants in the community, give yourselves another pat on the back. You deserve it!

Now to my actual question :-

Is there some type of standard thread-safe data structure that one could use for 2 way communication between multiple Editors and a single Processor? A recommended approach to doing this in general? Or is it more nuanced to the specific usage?

From tutorials and past forum topics, I have seen a few different things. From the use of atomic variables, locks/critical sections, lock free FIFOs to the AudioProcessorValueStateTree (APVST).

I guess I was looking for a general purpose “thread safe” Value State Tree implementation, and was wondering if the APVST was just this, or if it was something more specific to the parameters that are exposed and saved out with the DAW state.

So if the editors/processor maintained a reference to a Value State Tree and were able to read/write to it on their own threads, or register listeners for value state changes. Without
completely falling over each other in the process. Maybe just be wishful thinking on my part? Thought I would ask anyways in case I was overcomplicating things by considering thread safety on a case by case basis, or whether this is kind of expected.

Apologies in advance if this has been discussed a lot already and I missed out on drawing a clear conclusion from those conversations.

Thank you.

1 Like
2

APVTS is only really used for managing parameters in a plugin. It uses a ValueTree internally to store the state of the plugin but if you don’t need any of the other features offered by the APVTS then you should just use a ValueTree.

To make it thread safe you can simply use a lock to manage access to the ValueTree, this is what APVTS does:

If you need it to also be real time safe then ValueTree’s probably not the best approach. Personally I would favour atomics for primitive types (or any type where std::atomic<T>::is_always_lock_free is true). You could maybe write a simple class for managing these values, or just stick them in the Processor.

3

Ah k, thanks for clarifying that the APVTS is only really for parameters.

I can take a closer look at the APVTS lock implementation and try and replicate it on my end for regular Value Trees. Or make use of atomics or other lock free structures (I think there or some examples on past forum threads) as appropriate for specific use cases.