# ValueTree for large scale applications (follow up question)

**URL:** <https://forum.juce.com/t/valuetree-for-large-scale-applications-follow-up-question/50702>\
**Category:** General JUCE discussion\
**Created:** [March 23, 2022, 9:13am UTC](https://forum.juce.com/t/valuetree-for-large-scale-applications-follow-up-question/50702 "2022-03-23T09:13:58Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [March 23, 2022, 9:13am UTC](https://forum.juce.com/t/valuetree-for-large-scale-applications-follow-up-question/50702/1 "2022-03-23T09:13:58Z")

</div>

Hello @dave96 (I really hope it was ok to ping you; sorry if I was mistaken)

I recently saw your talk [David Rowland - Using JUCE value trees and modern C++ to build large scale applications (ADC'17) - YouTube](https://www.youtube.com/watch?v=3IaMjH5lBEY) about ValueTrees. I really enjoyed it I wish it was like twice as long.

I have question about returning state from the audio thread to the “outside” world and it would be great to hear your opinion on this topic. As an example: I’d like to react on the midi notes being currently processed by my sampler (e.g. simple MidiMonitor, highlight the current sound). All this information is of course stored in atomics with a fixed array size (one entry per sampler voice).  
I was thinking on having one “pull”-thread, that checks periodically for the values and writes that back into a value tree. The rest of the UI can subscribe the value tree and do stuff as it pleases them with only getting notified when something actually happened. The pull-thread might check only every 100ms and once it picks up on a change schedules up to 5-10ms and then throttles back down when nothing changes anymore.

I’m sure you are having some similar situations in Waveform, would be great to hear from those.  
Thanks in advance!  
Best, Rincewind

---

<div class="post-metadata">

**Author:** ![dave96](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/dave96/32/8487_2.png) [@dave96](https://forum.juce.com/u/dave96)\
**Post date:** [March 23, 2022, 10:40am UTC](https://forum.juce.com/t/valuetree-for-large-scale-applications-follow-up-question/50702/2 "2022-03-23T10:40:32Z")

</div>

Yeah, generally polling state like this is fine. One thing I would say is that it doesn’t necessarily have to go via the ValueTree though. Sometimes its easier to create an object held in a shared\_ptr, have the audio engine update the contents of that (as atomics) and then poll it from your UI thread (which also has a shared\_ptr to it).

It really depends on your architecture but we tend to only keep things in the ValueTree that are _persistent_ state, i.e. saved and reloaded with the app.

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [March 23, 2022, 10:42am UTC](https://forum.juce.com/t/valuetree-for-large-scale-applications-follow-up-question/50702/3 "2022-03-23T10:42:32Z")

</div>

Thanks for that input! Haven’t thought of using shared\_ptrs this way, I’ll definitely try that out.