A second reason not to view ramps as finite is that it
requires
receivers to do one of two things:
1. Test for the target value for each sample. (Inner
loop conditional!)
2. Prequeue an event to itself to stop the ramping at
the right point. (Means you have to scan the event
queue for the right place to insert this event.)
Meanwhile, the sender must keep track of what it's doing anyway, so
it really doesn't matter whether ramps stop automatically or not -
there will always be a new event at the end of the ramp anyway.
OK, I'll buy that. Send a SET event to stop a ramp. It just means that a
ramp is (almost always) two events. Not too big a problem, I think.