How to attach plugin Editor & Processor to ValueTree state?


#1

Hi all,

Is it acceptable to store a plugin’s state in a ValueTree and attach both the Editor and Processor to the ValueTree’s properties using ValueTree::getPropertyAsValue? I am asking this because of the following comment in Juce::Value

Important note! The Value class is not thread-safe! If you’re accessing one from multiple threads, then you’ll need to use your own synchronisation around any code that accesses it.

In my case the Editor will read & write to the ValueTree, but the Processor thread will read only.

I do not wish to expose any automation parameters to the host, so AudioProcessorParameter feels like the wrong solution.

Are there any common design patterns for attaching Editor & Processor to a ValueTree state?

Perhaps each thread should have a CachedValue for each property on the ValueTree? Or each thread could have its own deep copy of the ValueTree and I could use ValueTreeSychroniser…?

Any & all suggestions greatly appreciated.


#2

Hi, there’s actually a tutorial for this:

https://www.juce.com/doc/tutorial_audio_processor_value_tree_state


#3

Thanks @leehu in my case I want to manually manage a deep, semantic ValueTree and I don’t wish to expose any parameters to the host, so I hadn’t given AudioProcessorValueTreeState much consideration. But of course I can go and have a read of those classes and I’m sure I’ll learn a lot about how to correctly manage thread synchronisation around ValueTrees.

Having said that, I think CachedValue was added to JUCE after AudioProcessorValueTreeState and may be intended for this sort of situation?