That’s an interesting idea. I’m not sure which way is better.
For fun, I compared it to the [function~] object from the Else library in Pd. It’s basically the same idea as IEnvGen – n+1 levels, n times, but only linear segments, with a signal rate input. When the envelope changes, it just jumps to the new output level – which is a fine behavior. I don’t think it’s necessary to wait until the time input crosses a segment boundary to update the endpoints.
[function~] avoids the problem of scanning the inputs for changes because it can accept both signal input and control messages directly. So [function~] can just calculate input and wait for a new list, updating only upon receipt of that list. SC UGens can accept only signals (ar or kr – kr is still a signal!). So “temporarily stored in some internal memory” would be the only way, given the current input format, to detect a difference between the current input values and the previous ones (which is separate from the question of when to activate the new values).
At this time, I’d probably lean toward a solution where the envelope data are stored in a RTAlloc-ed array, and the output is calculated based on that array (not directly on the control inputs). Something would need to look for changes and update the internal array accordingly. But I’m not wedded to that – if someone’s got a better idea, go for it.
I think I see your point, though sequencing segments continuously could be complicated this way.
hjh