ValueTree for large scale applications (follow up question)

General JUCE discussion
1

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 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

2

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.

2 Likes
3

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