19 Jan
2003
19 Jan
'03
10:19 p.m.
I realized a few more things about ramping when messing with
Audiality's voice mixers:
1) The STOP event *is* rather handy, as it has no value
argument to be calculated or processed. If you're doing
internal ramping (or coefficients) instead of using the
ramped value directly, STOP just means you stop ramping
your internal controls. SET (which is what you must use
if you don't have STOP) is supposed to *set* a new value,
obviously, and would normally result in the coefficients
being recalculated, regardless of current stat.
2) RAMP events with a <target_value, duration> aim point
do not guarantee *anything* but the value hitting the
aim point. Plugins are not required to perform truly
linear ramping; only something that "sounds similar".
If you would SET halfway to the aim point, you would
get a click, unless the receiver is doing *truly*
linear ramping internally!
3) Ramping with aim points means you don't have to know
where you are, to set up an accurate ramp to a desired
value. You don't even have to know if the current value
is above or below the target value.
Now, a STOP event before the aim point of a ramp in
progress would not always give you *exactly* what you
want, but close enough. (Provided the receiver "fakes"
linear ramping well enough - which it basically *must*
do anyway, for ramping to be usable.) Remember that if
you set up a new ramp, it will take you to the new aim
point regardless of the current value. So, as long as
you don't *SET* before (or after) the aim point, you're
safe.
4) Normally, you'd probably re-aim with RAMP, but in some
cases, you really just want to hold where you are
indefinitely. That's when you would use STOP - or fake
it with a "long" ramp to what should be the current
value. Both should work, but STOP is easier and faster.
5) A more serious issue is that if control events are not
allowed while ramping, except at the time of the aim
point, there is no way to avoid sending one RAMP event
for each block while ramping. You can't aim further
ahead than the first frame of the next block, or you
might have to break in and adjust the aim before you
hit the aim point.
This could potentially be a serious performance issue
with low latency hosts, since it means 1000+ RAMP events
(and the related transformation overhead) per ramping
control.
As a real life example of the alternative, the RT
envelope generator in Audiality uses one event per node.
(DAHDSR currently, which means 7 nodes.) Extra events
will have to be inserted to handle real time modulation
of the envelope (volume and pan controls, at the very
least), but there's never a need for more than one
extra event per linear section added.
Questions:
A) Is it necessary to require that aim points are
within the current block, to avoid "re-aiming"?
B) Is STOP useful enough to be in XAP?
Anyway, I think I have answered my own questions by explaining all
this (A: Yes, or complex effects won't mix with low latency, and B:
no, you'll probably end up using RAMP all the time anyway) - but I'm
still interested in comments. This might not be all there is to it.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---