Phijel

i have a strange problem here, i hope somebody can point me to a solution, 

i have a poly [cycleur3], with a random amplitude enveloppe generator inside [random_adsr].

When receiving notes from the parent patch, (with a [prepend note]) it is working fine at the beginning, and continues to do so for a couple of times for each voice, but then after a while, it simply stops receiving notes, and the voices are becoming unavailable one after the other, and the patch is becoming silent (excepted maybe for 1 voices that continues working)

But If i open a silent voice from the parent patch, i can see the toggle from the thispoly~is on (1), and the number~ from the random_adsr is 0., meaning it is supposed to be available, but it doesn't receive anything and does not produce any sound).

Sometimes also, the scope inside the poly shows a frozen non-zero state, but the number~ out of itt indicates 0

And if i manually bang the button on top af the [random_adsr], the voice starts working again (well, not always but almost)

this is the random_adsr abstraction inside the poly:

i have a strange problem here, i hope somebody can point me to a solution, 
i have a poly [cycleur3], with a random amplitude enveloppe generator inside [random_adsr].

But If i open a silent voice from the parent patch, i can see the toggle from the thispoly~is on (1), and the number~ from the random_adsr is 0., meaning it is supposed to be available, but it doesn't receive anything and does not produce any sound). 

trouble-with-mute-busy-state-within-a-poly

Hi, took a quick look, there's 2 ways to turn off a poly~'s busy state, one's a signal, and the other is with an integer, 0 or 1. But I'm not sure it's such a good idea to use both.

Also, probably the main problem I was finding is that your patch has a weird sustain timing mechanism. You could simplify that by taking advantage of semi-sample-rate timing using the line~ object. Just send line~ a message with something like "! $!" and the second argument is the time you wish the sustain to be. Then out of line~'s second outlet(signalling when the ramp is done), use a trigger object to send a 0 to the line`(to reset it) and a bang to the 0 which ends the sustain portion of adsr~.

One more thing, I took the "mute 1"/"mute 0" messages and gave them a different placement which might also be making a big difference(and just for security, you may want to put a loadbang triggering the message, "0, mute 1" to initialize thispoly~ properly).

and here's the outer test patch i use, oh, by the way, i changed it to use "midinote 64 64" type messages but you can probably change this back, you'll have to take the unpack and stripnote out of the actual cycleur3 poly~ if you do, though:

There's also ways to use the signal to turn off "thispoly~" but i figured the messaging seems to suit your needs just fine.

Hi, took a quick look, there's 2 ways to turn off a poly~'s busy state, one's a signal, and the other is with an integer, 0 or 1. But I'm not sure it's such a good idea to use both.
Also, probably the main problem I was finding is that your patch has a weird sustain timing mechanism. You could simplify that by taking advantage of semi-sample-rate timing using the line~ object. Just send line~ a message with something like "! $!" and the second argument is the time you wish the sustain to be. Then out of line~'s second outlet(signalling when the ramp is done), use a trigger object to send a 0 to the line`(to reset it) and a bang to the 0 which ends the sustain portion of adsr~.

on second look, i made a typo, should be the message "1, $1" to the line~ object. i also notice some weirdness while editing a poly~ and then restarting the patch(i need to turn dac~ off and on again to get it going properly, hopefully that won't happen to you but if it does, hopefully at least all of this can help set you in the right direction) and here's a better test patch (just an ezdac~ to make it quicker to turn on):

Ay caramba, yet another typo, "1 $1"(no comma) to the line~ object, but if you look at the patch I pasted it has the correct message, anyways. OK, that's all I will obsess over this. Best of luck.

Many thanks for your patches and your comments, unfortunately, it doesn't solve my problem :-(((

The main patch becomes silent after a while (maybe 2-3 minutes, and several successful triggering of all the voices), and i don't see any logical explanation to this behavior

for info if you want to try, here's my main (unfinished) patch below.

I renamed the poly~ cycleur4 and the one inside it random_adsr2 (these are your modified patches)

Also, in your modified random_adsr2 patch, sometimes it gets blocked on sustain without triggering the release stage, i also cannot understand why.

Ok, i got it working fine now, without using the mute outlet of the [adsr~] *at all*, but only connecting the signal from the last [*~] juste before the outlet of the poly~, like this

ah, sweet, the signal solution. i should've just tried it. glad you figured it out. sorry to be so scatter-brained.

Trouble with mute / busy state within a poly~