18 Dec
2002
18 Dec
'02
6:28 a.m.
On Wednesday 18 December 2002 09.09, Tim Hockin wrote:
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.
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 ---
SET(...,
value)
RAMP(..., target, duration)
SPLINE(..., target, target_slope, duration);
do we really need spline? 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.