# RT read/write \<\> GUI read-only structure

**URL:** <https://forum.juce.com/t/rt-read-write-gui-read-only-structure/41998>\
**Category:** Audio Plugins\
**Created:** [October 1, 2020, 6:33pm UTC](https://forum.juce.com/t/rt-read-write-gui-read-only-structure/41998 "2020-10-01T18:33:16Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![refusesoftware](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/refusesoftware/32/20561_2.png) [@refusesoftware](https://forum.juce.com/u/refusesoftware)\
**Post date:** [October 14, 2020, 5:34pm UTC](https://forum.juce.com/t/rt-read-write-gui-read-only-structure/41998/6 "2020-10-14T17:34:01Z")

</div>

> [@sigmate](#):
>
> Also, they’d be stored along with the processor’s state, which is not needed (well, at least in my case).

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.

> [@sigmate](#):
>
> Today I wrote a very simple `RealtimePropertySet` class which encapsulates a `std::map<String, std::atomic<float>>`…

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](https://forum.juce.com/t/sending-signal-events-from-audio-to-gui-thread/27792/8), 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.

> [@sigmate](#):
>
> Most importantly, this work is heavily inspired by the Jukebox SDK from Reason Studios, which is now publicly available.

I’m curious, which part of the Jukebox SDK is inspiring this? I haven’t looked at that Reason stuff in years.

---

_[View the full topic](https://forum.juce.com/t/rt-read-write-gui-read-only-structure/41998)._