Well, basically it’s all there, because we have C++, but there are couple ways to do it wrong.
My request is, that juce could provide very solid building blocks of doing things right and easier, instead that everybody implements them in a own way and probably wrong.
For example exchanging heavy weight objects in the audio-thread.
There was an example of a release pool, which was promoted here in the forum (if I remember from @timur) . This used a mutex to save the internal array, in the end I didn’t solve the problem because it can cause performance intrusion, instead it created an overhead of source-code.
Or creating synth-voice objects in the audio-thread. Yes there are patterns like creating this objects at another thread, using a lock-free fifo to transport them to the audio-thread.
But if the problem behind it (the memory allocation which shouldn’t affect the audio thread) would be solved correctly, everything would be much easier. No workarounds would be required, just:
SynthVoice* s = new (Juce::RealtimeAllocator->allocate(sizeof(Synthvoice)) SynthVoice();
Another example is lock-free messaging. The audio-thread wants to signalise that there is some kind of overload or whatever, to update the GUI, yes it could set a flag, and then there is a second helper thread to read that flag and translate it into a message, basically a triggerAsyncUpdate() or sendChangeMessage(), the problem is that the current implementation of them can cause performance intrusion.
And solving these kind of problems, is what I like to see in a framework which is specialised in realtime audio.