[linux-audio-dev] XAP: Some thoughts on control ramping

[David Olofson]

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 ---