You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
I agree to follow the Code of Conduct
The text was updated successfully, but these errors were encountered:
Detailed steps on how to reproduce the bug
Create a
Sampler
/Synthesizer
and add a newSynthesizerSound
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()
andclearSounds()
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
branchI have not tested against the
develop
branchCode of Conduct
The text was updated successfully, but these errors were encountered: