These are some of the shapes Env accepts:
*dadsr: delay, attack, decay, sustain, release.
*adsr: attack, decay, sustain, release.
*asr: attack, sustain, release.
*cutoff: sustain, release.
The default values, the order, and the names of the parameters follow a coherence for the first three, but in cutoff the releaseTime is 0.1 instead of 1 and is placed before level; level is called like that instead of sustainLevel, and curve is lin instead of -4.0.
I propose creating an alternate way, *sr, for specifying an envelope with only sustain and release; its arguments being: (sustainLevel: 1.0, releaseTime: 1.0, curve: -4.0).
Why not just use the Env.perc method which also gives you the attack time?
Env.perc is a timed envelope (gate is a trigger). Env.cutoff is a gated envelope (gate is a gate). If you need a gated envelope, that would be a reason not to use Env.perc.
(Or, delete cutoff and advise users to use asr with attack time = 0. Actually I’m not sure why so many methods: asr is just adsr, with sus = 1.0.)
hjh
I guess asr exists because it also exists in some physical synthesizers.
I also think this family of methods exists because the defaults of the every ‘more flexible’ method aren’t achievable with a less flexible one.
For example, the defaults for adsr make a characteristic adsr sound, but if one would want to use it as asr, they would need to change the sustainLevel to 1. But sustainLevel is after decayTime in adsr, so a user wanting to use adsr as an asr should either type an arbitrary value (0 would make the most sense) for decayTime, or use the parameters with the keywords. Moreover, if they wanted to change the real sustain level of an adsr envelope, they would have to change peakLevel, which isn’t that intuitive. That, or multiplying the whole envelope by something. Furthermore curve, a setting that actually would make sense for this envelope, is after the somewhat ‘confusing’ peakLevel.
cutoff seems out of place to me for its specifity, for the non-coherence with the other methods and because the word suggests filter frequencies to me, and not envelopes.
My first choice would be to soft deprecate Env.cutoff and provide the more coherent Env.sr as an alternative; I feel there can be situations where an attack just doesn’t make sense. My second choice would be the one you mention; just soft deprecating Env.cutoff.
1 Like