![](https://secure.gravatar.com/avatar/fa5a8de5c6e6c5838fc8106b390c7a6d.jpg?s=120&d=mm&r=g)
Fellow ChucKists,
Envelope.rate() is a read-write function so I thought I'd try to use it to
detect the current movement of a envelope, like this:
=========================================
Envelope e => blackhole;
e.value(0);
e.duration(second);
e.target(1);
now + 3::second => time later;
while(now
![](https://secure.gravatar.com/avatar/8a1ca9f288a1644e9e07d7f11d2f494c.jpg?s=120&d=mm&r=g)
+1
Yes, I think that makes much more sense, for what it's worth.
-mike
On Wed, Jun 18, 2008 at 9:03 PM, Kassen
Fellow ChucKists,
Envelope.rate() is a read-write function so I thought I'd try to use it to detect the current movement of a envelope, like this: ========================================= Envelope e => blackhole;
e.value(0); e.duration(second);
e.target(1);
now + 3::second => time later; while(now
>>; 10::ms => now; } ================ It now turns out that .rate(), when read from, reports the rate of change Envelope had when it was last set to a target, not necessarily it's current rate of change (which may well be 0).
I'd like to propose this behaviour to be changed towards Envelope always reporting it's current rate of change.
Because Envelope is a part of the STK we may need to be careful with that as other Ugens inherit from it so such changes might affect those. Still; there are a few STK Ugens that are on The List to have a look at because of their envelope (probably ADSR) based behaviour anyway. Stricktly speaking this change could break some ChucK code as well but I find it hard to imagine situations where the current behaviour is more usefull then my proposed change.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://semiotech.org http://deadlylittlepills.com/michael
![](https://secure.gravatar.com/avatar/2b106a766c761b174a0734125b8de1c0.jpg?s=120&d=mm&r=g)
I suppose I'll chime in my support for this functionality, as it makes
sense, though it does seem like it'd be harder to implement.
-Kevin
On Wed, Jun 18, 2008 at 10:13 PM, mike clemow
+1
Yes, I think that makes much more sense, for what it's worth.
-mike
Fellow ChucKists,
Envelope.rate() is a read-write function so I thought I'd try to use it to detect the current movement of a envelope, like this: ========================================= Envelope e => blackhole;
e.value(0); e.duration(second);
e.target(1);
now + 3::second => time later; while(now
>>; 10::ms => now; } ================ It now turns out that .rate(), when read from, reports the rate of change Envelope had when it was last set to a target, not necessarily it's current rate of change (which may well be 0).
I'd like to propose this behaviour to be changed towards Envelope always reporting it's current rate of change.
Because Envelope is a part of the STK we may need to be careful with
On Wed, Jun 18, 2008 at 9:03 PM, Kassen
wrote: that as other Ugens inherit from it so such changes might affect those. Still; there are a few STK Ugens that are on The List to have a look at because of their envelope (probably ADSR) based behaviour anyway. Stricktly speaking this change could break some ChucK code as well but I find it hard to imagine situations where the current behaviour is more usefull then my proposed change.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://semiotech.org http://deadlylittlepills.com/michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
![](https://secure.gravatar.com/avatar/fa5a8de5c6e6c5838fc8106b390c7a6d.jpg?s=120&d=mm&r=g)
2008/6/19 kevin
I suppose I'll chime in my support for this functionality, as it makes sense, though it does seem like it'd be harder to implement.
Not by much, I think. This is the "essence" of Envelope, it comes from Ugen_stk.cpp, starts at line 6972; =============================- MY_FLOAT Envelope :: tick(void) { if (state) { if (target > value) { value += rate; if (value >= target) { value = target; state = 0; } } else { value -= rate; if (value <= target) { value = target; state = 0; } } } return value; } ============
So; that has clauses for having reached the end already anyway, so what we simply could do would be; ================= MY_FLOAT Envelope :: tick(void) { if (state) { if (target > value) { value += rate; if (value >= target) { value = target; state = 0; rate = 0; } } else { value -= rate; if (value <= target) { value = target; state = 0; //not sure we actually need this line? rate = 0; } } } return value; } ============= I think that would fly. I am, BTW, not sure why there are separate "rate" and "state" variables... and I can't seem to find the getRate() one. Also; in ChucK .rate() will always be a non-negative value. Maybe it would be best to have .rate() (in ChucK) report a rate with the appropriate sign as we don't have access to .state() from ChucK.... of course in that case we could also add a little check and if rate == 0 immediately proceed to returning value, in the interest of saving CPU. Yours, Kas.
participants (3)
-
Kassen
-
kevin
-
mike clemow