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

[David Olofson]

On Monday 20 January 2003 16.15, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson wrote:
> > 	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.
>
> I dont see why there is a restriction on aiming further ahead than
> the current block, this seems like a mistake. It forces the plugins
> to be closed to linear than is desirable.

I totally agree on this. The reason why I'm bringing it up is that it 
was originally suggested that a RAMP event refers to a specific range 
in time; basically a "macro event" that describes two actions; one 
now and one at the end of the ramp. (Physically, the latter action 
would be "stop ramping", although that has been ruled out as tricky 
to implement while not useful.)


> > Questions:
> >
> > 	A) Is it necessary to require that aim points are
> > 	   within the current block, to avoid "re-aiming"?
>
> I dont see why, the obvoius inner loop for ramp aiming should deal
> with this perfectly well, it will just replace the delta_control
> number.

Exactly.


> > 	B) Is STOP useful enough to be in XAP?
>
> I'd argue for it not be be there. Its hard to see when it would be
> useful ,ad its one more thing to handle.

Agreed.

At the time, it happens to be a shortcut in Audiality, but as soon as 
I implement modulation of the envelope generators, that shortcut will 
be essentially useless, since the hold and sustain sections will no 
longer be guaranteed flat. (The EG will basically be multiplying the 
envelope with one or more streams of control events.)


> SET /could/ be done with a ramp with target time of 0, not
> optimally efficeint,

OTOH, this test must be done somewhere anyway. (Audiality does it on 
the sender side, as it has SET + RAMP.) It could be argued that with 
pre-recorded event streams, it's better to use SET, as that 
eliminates the run-time conditional altogether, but I'm not sure it's 
worth it. (It's just one very simple test...) For control streams 
generated on the fly, it doesn't matter much where you do it.


> but the cases I can think of it wont hurt:
>
> notched switches: will always jump to the target value anyway, so
> wont have to do any interpolation.

RAMP is always interpreted as SET? Not the best way to fake ramping, 
but then, if you say you do not ramp, you shouldn't be expected to 
even fake it. Makes sense.


> continuous controls: SET operations will be quite unusual, and the
> overhead is not that big.

So, alternative 1; RAMP events only:

	  case XAP_A_RAMP:
		if(ev->duration)
			dvalue = (ev->value - value) / ev->duration;
		else
		{
			value = ev->value;
			dvalue = 0.0;
		}
		break;

	- Adds a receiver side conditional for decoding, even if
	  the input is prerecorded.
	- Contrary to the normal logic, duration == 0 implies
	  that ramping is *stopped* by the RAMP event.
	+ Senders don't have to check for 0 duration.
	+ duration == 0 becomes a valid and logical case.
	+ Won't blow up if a 0 duration is "accidentally" sent.
	+ More streamlined API; only one event per control type.


Alternative 2; RAMP and SET:

	  case XAP_A_SET:
		value = ev->value;
		dvalue = 0.0;
		break;
	  case XAP_A_RAMP:
		dvalue = (ev->value - value) / ev->duration;
		break;

	- More events in the API.
	- Senders must replace 0 duration RAMPs with SET.
	- Sending 0 for RAMP duration may have plugins blowing up.
	- Turns "ramping with dv == 0" into a special state.
	+ No extra conditional for duration; switch() is full decode.
	+ No 0 duration testing at all when playing prerecorded events.


Using only RAMP events definitely looks like a great idea to me. I'm 
going to try it in Audiality right away! :-)


BTW, using INFINITY for duration (MAXINT for fixed point, provided 
MAXINT is not a valid control value) has the same effect as a STOP 
event... Should this be allowed? We've already concluded that the 
STOP action - whether it's an event of it's own or not - isn't very 
useful, so maybe we should just leave this in the "undefined 
behavior" domain.

And yes, duration would be of the same type as the control value, I 
think. There's no point in making it an integer for float controls, 
since plugins will only use it for a aim point -> dv transformation 
anyway.


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