send always the same note with different durations to play each time a fragment of a long sample (6'30") in a [poly~] and be able to change pitch (and reverse) on the fly.

Problem : sometimes (and I can't find exactly in what conditions), the ADSR doesn't close envelope and the sample stays in loop (if enabled) or play until the end.

I tracked informations and the right data seem to be sent; just the adsr seems to stuck.

"In Audio Interupt" is off because when it's on it lose mididata from sensors...

Here's the goal :
send always the same note with different durations to play each time a fragment of a long sample (6'30") in a [poly~] and be able to change pitch (and reverse) on the fly.

using-of-poly-a-bug-in-my-patche

yeah , the thing is that perhaps you are trying to CLOSE adsr in wrong voice . you need to send your "stop" to the right voice . via target message to poly object . so you need to track your activated voices . "thispoly" provides such information that you can route out from poly and use it for target .

I forgot to mention the message to poly is "note 60 127 10000 10500" (pitch, velocity, start, end) to let [poly~] manages itself the busy states.

As you can see in the simplified patch, the ADSR is closed inside the poly, then it can't be the wrong voice.

but in a way you're right, I can try to manage [poly~] from outside with [poly] and "target" messages.

for now I'm trying a new way with the "maxsustain" message to [adsr~]... will see...

I forgot to mention the message to poly is "note 60 127 10000 10500" (pitch, velocity, start, end) to let [poly~] manages itself the busy states.
And [poly~] is in "steal 1" mode.

for now I'm trying a new way with the "maxsustain" message to [adsr~]... will see...


yes is see it . it should close itself as i deducted from your patch . or the pipe is a problem , just for testing try to replace it with "delay" and bang 0 from it . just to be sure

I did it already. and with a stop message before sending 0 too...

still don't know why it didn't work well but I suspect it had to see with the "steal 1" attribut.

but finally it seems I got it working with another strategy using "maxsustain" message.

I did it already. and with a stop message before sending 0 too...
still don't know why it didn't work well but I suspect it had to see with the "steal 1" attribut.

yes weird . at least you have got cleaner patch now

using of [poly~] a bug in my patche...