Seeing forest from the ValueTrees

I am new to Juce. Looking for big picture viewpoints about how and when to use ValueTrees and States, without getting too lost in the weeds and details.

I can immediately see the benefit of linking GUI controls to ValueTree States in order to keep a ValueTree and GUI item in sync. I can immediately see the benefit of easy serialization of ValueTrees. Still trying to form in mind the best practices for constructing a program/plugin architecture that is using value trees in the best way without overcomplicating certain things. Hoping for some wisdom from some of you that have been using them a while. Again, big picture as much as possible here…

Let’s say I have a design that will involve some semi complex sub-components which will be abstracted as classes for easy reuse. Inside them could be many controls. And then a higher level GUI…and then there could be different GUI screens, etc…

So first question do people tend to use one ValueTree per component? Or per window? Or one giant Valuetree per plugin?

If you end up with a collection of different value trees representing all the data, how do you go about serializing them all? Do you combine them into one value tree and then serialize that the easy way? Or what is a good strategy that has worked well for saving state of many different value trees, some of which could be nested within nested UI relationships, etc…??

I noted in David Rowland’s 2017 ADC talk that he mentioned its common for him to have some non-valuetree variables that are using for the audio thread in process block, but then he populates those in an atomic state outside of the process block I guess, and basically only interacts with the various valueTrees outside of the audio thread. Is that a common thing?

Again, just looking for high level wisdom as I architect my first project which is not super complicated, but not super simple either. Plus I really want to learn about valueTrees and states since that seems to be the JUCE way of doing things and I want to be on board with it, so no time like the present.

any ideas or opinions welcome here…

It all depends on the complexity of your design. Since a ValueTree is now used to store plugin parameters by default, I guess many newcomers just attach their own custom data to that ValueTree and keep that one mostly flat with all the parameters on the top level. If your plugin state mostly depends on plugin parameters, this is probably the easiest way to do things. You also have to keep in mind that only the parameters are visible to the host and to automation.

For my plugins I use one giant nested ValueTree and use my own (pre Juce-5) parameter code to attach parameters that can be any property on any level.

Having just one main ValueTree enables serializing the whole state to xml or binary. It also allows you to do your own preset management easily and to have undo support for everything.

It’s definitely bad to manipulate ValueTree data on the audio thread. You might get away with just reading some properties, but it is a good practice to just not use any ValueTree methods at all on the audio thread.

1 Like