Communication Between UI Thread & AudioThread with complex Midi Plugin


I’m still learning Juce and C++ so there maybe some mis-understandings on my part of various strategies for communicating between threads!

The situation is this, I’ve been constructing quite a complex midi plugin - there are modular elements, complex arpeggiation and various other things going on under the hood and I’m trying to settle on a strategy for communicating between the UI thread and the Audio thread.

The state of the UI is stored in a valueTree and my idea based on various things I’ve read on here is to create a ‘permanent’ proxy class that contains all the members of the valueTree and is updated as and when the valueTree is updated, but with primitive data types so that they can be read quickly on the audio thread. I would then copy that object to a second object of the same type, and pass a pointer to the copied object across to the audioThread using a FIFO queue.

I’m still figuring out the details, but before over-investing in the strategy I just wanted to see if others thought this was a viable approach?

depends what you mean with “modular elements” and stuff. often times you can optimize things by setting a limit to how modular it is. for example you could say there can be infinitely many modulation connections between modulators and parameters, but then you have to find a really smart way to update the given vectors safely and suddenly you end up writing fifos or release pools and stuff. but you can also just say “ok there are max 128 modulation connections, and they always exist, but they are just not always used” and you don’t have to consider any thread safety anymore, just make some primitives atomic etc

1 Like