The documentation for the state (ValueTree) in the APVTS suggests, that I should be allowed to add custom stuff to the value tree. In my case, this is one child tree containing optional comments for audio parameters. I created a wrapper class for the additional attachment containing the original component attachment and the ValueTree listener to react, when the comment property concerning the parameter changes.
Works great so far. BUT how about the thread safety? I feel like I should be locking the critical section inside APVTS when I update the value tree property in my attachment class. But it is not accessible. But if I have no access to the critical section, what would I be allowed to change in the value tree?
i think when the documentation of ValueTree said you can add custom stuff to it, it didn’t mean that you should make inherited classes of ValueTree, but more like, that you can just add more children and properties than just the parameters to it. apart from that you can just let getState or setState lock if you’re unsure if stuff is thread safe in it. saving and loading a state is not something that should happen while audio is being processed anyway as it can lead to buffers being resized and stuff
This is not a good solution as both methods create uncessesary overheads concerning the actual parameters.
Just because it „should“ not happen, doesn‘t mean it does not happen. By that logic you could remove the locking entirely. Not to speak from the fact, that I‘m not trying to sync with the audio thread (the audio thread doesn‘t care about some comments the user sets) but with the thread that is calling setState and getState. And the code should neither imply that the mechanics changing the comment (= the property in the value tree) nor setState and getState are called from the message thread. So there is potentially a third thread that needs to by synchronized.
That may be be general rule but I think we can both agree that this is not the case for the value tree in APVTS. Otherwise, we wouldn’t need the locks in getState and setState
That’s exactly what I’m trying, but I can’t since I don’t have access to the critical section I’d need to lock. Therefore my question, without the critical section being accessible, what was the JUCE team thinking when they wrote the documentation. What am I allowed to do without the hole thing blowing up.
There are locks around load/save preset but not around general usage of the VT. Generally speaking despite it’s name, the APVTS is not really something that protects your data in a “real life way” beyond a few use cases like preset load.
For that to work in a reliable way, I think you need to store your data in something that isn’t the APVTS, protect that using locks or FIFOs, etc, and only put it in the APVTS during get/set state where the APVTS itself is locked.
If any one else is curious for the working solution I came up with:
I’m using an own value tree just for the comments and just copy that stuff in for load and save state. So the APVTS really has nothing to do with it anymore.
Concerning the locking, here is some stuff to look out for:
Since load and save state are most likely not called from the message thread you have to sync that with your component attachment. You can use a critical section safely as the audio thread doesn’t participate in the comments. Make sure to also close your lock when creating the attachment as you most likely will query the current comment on creation.