adsr~ makes clicks even with sustain of zero?
Hi folks, I haven’t posted in a while, and I hope to be more active…I stumbled on a strange anomaly. After some time trying to declick the adsr~ when it enters a fast release phase or a new note starts, I tried setting sustain to zero, and the envelope still clicks the same amount on gate on/off events. Is there any explanation? I never had that experience before….I don’t think any amount of smoothing can remove clicks that occur when sustain is zero, but maybe I don’t know something that I should….
I think it is the regular behaviour of an adsr to go to 1. after the attack-phase, so it should click if attack or decay are short enough, regardless of the sustain value. Maybe i misunderstood you. at what a/d/s/r values do you get clicks?
You don’t give a lot of info abot your situation, but I think I know what your issue is.
in my experience it is best to have 2 voices alternating eachother if you want a monophonic synth. In that way each of the 2 adsr-s enjoy their full envelope.
A poly~ with two voices should work, then you can use the mute outlet of the adsr to stop dsp processing. Look at the polysynth example in the adsr~ helpfile
I think this is actually a reasonable complaint.
If you have an ADSR with A = D = 0, it is reasonable to expect the envelope to start at S.
Just a guess here, but I suspect that internally, [adsr~]‘s minimum A and D times are 1 sample, to prevent a divide-by-zero when calculating the slope delta.
When A = D = S = 0, the ADSR should always output 0. A click at the start of the envelope indicates that [adsr~] erroneously jumps to 1 (because A = 0), before dropping to S on the next sample (assuming it respects D = 0), or perhaps even after 2 samples (assuming minD = 1 sample).
But implementing a ‘correct’ ADSR requires a few more conditionals in the DSP loop, which would add some performance overhead.
I think most ADSRs will always go to their max, even with all stages set to 0. They go through the cycle, and that means hitting 1.0 at the top of the attack segment.
Whenever audio is gated, unless there is some fade time, there will be a click. I think Timo is on the right track with using poly~ and letting the voice allocation do its thing. This way you can let the ADSR have a reasonable shape that is fast enough to do what you want it to do, but slow enough so that there are no clicks.
Thanks, I understand! The A stage goes to gate value before it checks sustain, then drops to S value at D rate. So if S=0, there is at least 1 audio sample, possibly two, before it gets to sustain level! That causes click. So, I should check sustain level !=0 before sending non-zero gate into adsr~, which doesn’t perform this check for better performance. No problems!
I am trying to get a poly~ version working. I’m confused about the interaction of the active and mute flags. For adsr~ to choose an inactive voice, do I set TARGET=0 so the gate event goes to all voices? If I set STEAL=1, How does it know which voice to steal? I’m wanting an LRU selection, do I need to code that manually?
Those are some really clean designs, Chris, thanks for the pointers ) I’ll try making my architecture as straightforward.
Does pcontrol mute the audio also, or do I set both mute~ and pcontrol to turn everything off?
Not sure what you mean by pcontrol here, but to stop the MSP side from burning cycles on unused voices, and keep the voice allocator happy, you send both the mute message and the 0/1 for busy state.