Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Wed Dec 18 2002 - 12:22:44 EET
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 ---
This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 12:25:23 EET