davidestevens

I don't know whether or not I'm missing something here, but in a sub patch, when you send a noteoff (ie 0. to the first inlet) the first outlet of [adsr~] returns to 0. as you would expect, but if the same patch is inside a poly~ it _never returns to zero. In fact it returns to a different non-zero value every time, at least on my laptop. I'm thinking of using the 0. from the 2nd outlet to force zero but that seems a bit kludgey. Any idea why the ADSR isn"t going to zero, and what I can do about it? I'm assuming this is why I'm having problems with the behaviour of this patch (only works with steal on, clicks at start of notes, splats at ends, notes not being available. Aagh!)

(I've tried changing vector sizes, turning scheduler in audio interrupt back on, none of which changes anything)

In the main patch you can open the sub patch and by clicking on the 1 & 0 messages to [adsr~] see that the output goes to zero. then do the same with the poly~ and you"ll see the adsr~ returns to some non-zero value. The iGate is just something I put there while I was trying to figure this out in situ.

MacBookPro; latest OSX, latest Max.
Patches pasted below.

adsr-out-wont-return-to-zero-in-poly

the [adsr~] disables the DSP processing via sending a mute message to [thispoly~]. But the [number~] display is not fast enough to show the last value (e.g. the zero at the end of the release) after the poly instance has been muted. So look at the signal outside the [poly~]. It should work as you expect... hopefully.

Aha! Thanks Stan. That explains the last bit of that particular puzzle.

ADSR out won't return to zero in [poly~]