[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Wed Dec 18 05:29:01 UTC 2002


On Wednesday 18 December 2002 09.09, Tim Hockin wrote:
> > 	SET(..., value)
> > 	RAMP(..., target, duration)
> > 	SPLINE(..., target, target_slope, duration);
>
> do we really need spline?

Probably not. AudioUnits doen't have it (yet). Not sure about DXi. 
VST doesn't have ramping at all. (It doesn't have a real automation 
interface in the first place, so that's kind of expected.)

Would be cool though, and not terribly hard to implement in many 
cases.


> How many plugins are going to implement
> that?

It's not very hard to do for basic stuff, and it means many plugins 
won't need any internal filtering at all.

OTOH, it might complicate things a little for those that ramp 
internal coefficients rather than the actual control value. Then 
again, it's completely legal to ignore the slope arguments and do 
linear instead.

You should probably indicate what you do through a hint. One of these:

	SPLINE:
		Doing the whole thing, producing the exact same
		results as the SDK macros.

	LINEAR:
		Just linear. SPLINE events are shorted to RAMP.

	APPROXIMATED_SPLINE:
		Trying to do splines, but may not be 100%
		compatible with the macros in the plugin SDK.

	APPROXIMATED_LINEAR:
		Trying to do linear, but may not be 100% linear.

	STEP:
		Can't ramp, but will approximate ramps through
		"stair stepping".

	CONSTANT:
		Can't ramp, and can't fake it. Will latch target
		values instantly if RAMP or SPLINE events are
		received.


> If the host wants to approximate a spline, send multiple
> short linear ramp events.

Yeah, but that has the same problem as linear interpolation in audio. 
(Overtones that sound something like triangle waves.)

Many effects will make this audible, and thus, will need to implement 
filtering internally anyway. Splines can probably eliminate this in 
most cases.

We should probably try it though. Anyone around here has real 
experience with this?

Maybe we should ask the music-dsp folks as well.


> Then you only need timestamp (start),
> duration, and value. The plugin just has to arrive at that value
> by the end of the duration.  Slope is implied.

You only need one extra argument for splines; slope. Just like there 
is a current value that you ramp from, there is a current slope. Both 
are defined by previous SET, RAMP or SPLINE events.

This way, the three events mix nicely, and you also get some nice 
bonus features such as elimination of rounding error build-up, and an 
easy way of implementing declicked connections and disconnections.


> > >      beat number
> > >      tick number
> >
> > I would think you only really need one of these, since you can
> > calculate the other if you really need it. (Ask for time info, or
> > track meter changes, or whatever there is.)
> >
> > Anyway, these would both have to be doubles (64 bit), since
> > integers would introduce large rounding errors (can't have *both*
> > timestamps and positional data as integers), and float (32 bit)
> > have insufficient resolution.
>
> beat events could be integral - the host sends the beat #
> timestamped to the very first sample at or beyond the beat edge.

But then you only have sample accurate timing. Why aim low? ;-)


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



More information about the Linux-audio-dev mailing list