MPESynthesiser::renderNextSubBlock() currently has a data race against all the voice-modifying functions like
MPESynthesiser::clearVoices() etc. because it also uses the voices. I actually had crashes because of this. Adding
const ScopedLock sl (voicesLock);
renderNextSubBlock overloads as well as
turnOffAllVoices (which also has this race) fixes the crashes for me.
In addition, there are other dodgy-looking locks like
MPESynthesiserBase::noteStateLock, whose only purpose seems to be locking
renderNextBlock but afaics they can’t be called concurrently anyway? It feels this could be simplified and the number of locks reduced, but at the moment this doesn’t cause me any observable problems (unlike the
voicesLock issue described above).
Would you be so kind and look into this? Thanks