These look like they are always called synchronously. Is there any reason not to use them on a critical thread?
No other threads will be touching the underlying data.
ValueTrees are synchronous so probably would be ok (I think..) But Values do send messages on the message thread, so they wouldn't be ideal - changing them will invoke an AsyncUpdater, which will post a message, and that can block long enough to mess up an audio thread.
I’ve been wondering this today. What I’ve decided on is to create a simple struct to store values from the audio thread (e.g. meter levels), which can then be picked up by the message thread /via a timer to update the GUI. Every other aspect of the app’s state can be stored in a ValueTree.
What made me wonder is I’ve heard that Tracktion is written as one big ValueTree. Surely there must be some things, (like meters) that are not stored in ValueTrees?
I’m wondering about this again, and haven’t found a clear answer yet. My current assumption is that accessing a ValueTree property from the audio thread is OK, but updating should be done on another thread to avoid potential blocking from listener callbacks. I noticed there is also a setPropertyExcludingListener - if my assumption is correct perhaps this would be safe to use in a critical thread?
No! If you’re modifying the ValueTree on another thread then that could happen halfway through your audio thread reading it, so could read garbage or even crash.
Try the CachedValue class for this kind of use-case.
OK, thanks for confirming!
Than you should update your tutorial, it based on wrong assumptions regarding thread access
No… the tutorial accesses value via the parameters, not a ValueTree (?)
have a look at the other thread