, find the 2, check out the image with a green A and orange D and … In this case, we need only 5 numbers to control the amp sliding and duration. For 3.10, the attack level should always equals to the main amp value. The sustain time should equals to the [duration you hold the key]-attack time -decay time. So, the new algorithm should contain 1 attack 2 decay 3 holding duration 4 sustain(level) 5 release. Only 4th is level, others are all times. 2 parameters less than the implement now.
btw
play 60,attack:3,attack_level:3,decay:3,decay_level:0,sustain:3,sustain_level:3,release:3
It’s wired.
I may be wrong @yagaodirac but I suspect one of the reasons it might have been implemented this way was to simplify the design enough (for example) to make it easy for children to pick up, since it makes the sustain duration explicit, rather than implicit. (They don’t have to extra calculations to work it out, they can write it in directly, it simplifies the API, etc).
thanks for your thoughts about the current implementation of envelopes in Sonic Pi.
We don’t currently have any notion of duration, so we are unable to automatically calculate the sustain time as you describe. It would be interesting to consider adding such a thing, but that would result in an extra option, as I definitely value flexibility and simplicity over compression in this case.
With respect to the :amp option being able to replace the :attack_level, I prefer the current approach which sees the :amp as a multiplier over all the values in the envelope. This way you have more flexibility - again at the cost of compression.
Out of interest, why would you value finding the minimum number of options - especially when that reduces flexibility? Is there anything that the current implementation specifically stops you from doing?