Right, storing these values is not needed. The use case I often hear for AudioProcessorValueTreeState::state is to use it store GUI window sizing/positioning – i.e. something you do want stored, but also something you don’t want to allow host automation access to.
I’m curious how you are handling access to the setter/getter methods of this class. As you stated above, you want the Processor to write these values, and the Editor to only read them, right?
Also, over in this thread, there has been discussion about not reading/writing atomics per-sample, and instead limiting access to atomics as a per-block operation, for performance/optimization reasons. So even if you encapsulated all the atomics within a RealtimePropertySet, you might still need a collection of floats to temporarily hold these values before writing them to the atomics at the end of the processBlock. (And those should in many cases be floats created “locally” on the stack, within the processBlock scope.) Just pointing out that attempts to keep all the variables needed for this idea in one tidy place starts getting a bit messy.
I’m curious, which part of the Jukebox SDK is inspiring this? I haven’t looked at that Reason stuff in years.