[poly~] stops functioning after a while
Hello,
While making a new polyphonic sampler, the problem I get with [poly~] is that after some time (say, 15-30 minutes at least), the voices remain "busy" though a zero should have been sent to [thispoly~]. If several voices are loaded, they don’t stop working all at the same time.
The [poly~] subpatcher mostly contains a [groove~] buffer player. The voice stealing feature is disabled. The samples are triggered with a "note-on"-[midinote( message and no "note-off"-[midinote( is sent to [poly~], as the samples have to be played entirely. The sample bank contains 315 samples that last 1, 2, 4 or 8 seconds.
I tried two methods for sending a zero to [thispoly~]:
- using [average~], as there is no amplitude envelope in the voices
- detecting the moment when the sync outlet of [groove~] reaches 1 (using [==~ 1] and [edge~])
With both, everything works normally for quite a long time, but suddenly for some reason the detection stops functionning (so the zero is not sent to [thispoly~] anymore.
"Reanimation" can be done these ways:
- changing the number of voices (which means, loading again the voices)
- switching to voice stealing mode for a short time (just for reactivating the stuck voices)
- opening the help patcher of [poly~] (!)
Did you have this problem in the past ?
Thanks for your help
-j
Can you post a simplified patch that exhibits the problem?
-Ben
Hello,
I discovered where the problem came from.
In this sampler, each voice can play any of the buffers. But these voices stop functionning if you tell it to play a buffer that doesn’t exist. Indeed, in my patch, a voice is set to "busy" as soon as you send it a playing message, but if there is nothing to play, there is no information for telling that the voice is "free" so it remains "busy" forever.
Actually, the buffers were labeled "1-smp" to "315-smp" in the DSP patch and … "0-smp" to "314" smp in the Java script that does the mapping between inputs and DSP procesing. For some compositionnal reason the "1-smp" buffer had to be played quite late, which is why it took some time to discover the problem … A stupid coding error, really sorry for this.
-j