[Bug]: previous SynthesizerSound is deallocated on the audiothread when replacing a sound

[hgroenenboom]

Detailed steps on how to reproduce the bug

Create a Sampler/Synthesizer and add a new SynthesizerSound object to it. Play a midi key on a midikeyboard to play the sound, the played SynthesizerVoice will now keep a reference to the sound object. Remove the sound from the Synthesizer object using removeSound. The SynthesizerVoice object now has the final reference counted object for the given SynthesizerSound.

Add a new SynthesizerSound object to the Synthesizer object. Play the same midi key so that the same SynthesizerVoice as before will play the new sound.

The midinote gets processed in processNextBlock -> startVoice. And finally in Synthesiser::startVoice the reference counted SynthesizerSound is re-assigned. Thereby releasing the final reference of the previous SynthesizerSound on the audiothread.

What is the expected behaviour?

I would expect the Synthesizer class to automatically prevent me from any deallocations on the audiothread.

Or if this is too complicated, to at least warn me that I should not remove sounds after the Synthesizer has started playing. Either with a jassert or from the documentation.

I think the documentation of removeSound() and clearSounds() could also be improved. They both describe that they delete the sounds, suggesting (to me) that they are in fact deallocated after those function calls. While any SynthesizerVoice instance could still keep references for a very long time after those function calls if they are not played.

Operating systems

Windows, Other

What versions of the operating systems?

Windows 10, but this should apply to every OS

Architectures

Other, 64-bit

Stacktrace

No response

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

I have not tested against the develop branch

Code of Conduct

• [X] I agree to follow the Code of Conduct