JUCE's ValueTree structure can serve as a single source of truth for a plugin's complete state, driving all object creation

JUCE’s juce::ValueTree is a hierarchical, named property store that can be serialised to XML, observed for changes, and shared (by reference) across threads. In SOURCE, SourceSamplerAudioProcessor holds one root state ValueTree and all major objects — sounds, samplers, voices — are created and configured from it. When a preset loads, the XML is parsed into the ValueTree and the hierarchy rebuilds itself. When a parameter changes, the ValueTree fires a listener callback and only the affected object updates. This means the preset file, the in-memory state, and the UI state all describe the same tree — saving a preset is just serialising the tree. The pattern eliminates a class of bugs where the in-memory and on-disk representations diverge.

Examples

To add reverb to SOURCE, the developer adds reverbWetLevel as a property of the root PRESET node in the ValueTree. It is automatically serialised when saving, restored on preset load, and can be observed by the UI to update a slider, all without writing separate save/load code.

Assessment

What is the relationship between a SOURCE preset XML file and the in-memory ValueTree state? What happens to the plugin’s objects when a new preset is loaded? Why is the ‘state as truth’ pattern advantageous for plugin development?