13 Dec
2002
13 Dec
'02
9:06 a.m.
Maybe I don't get all the issues, but the following
thoughts occur to me wrt
time.
* A tempo delay that starts a delayed sound just before the host loops the
play back in (musical) time does not really want to know about absolute
musical time, but DIFFERENCES in musical time. More precisely, it wants to
be aware of the passing of ticks (where the duration of a tick is defined by
the host).
* What if plugins that care about musical time have a TICKS control.
Whenever the host crosses a tick boundary, it sends a (sample-accurate)
ardour uses 1920 ticks per beat. if the beat is 180 bpm, that's 5760
ticks per second, or 1 tick every 8 samples at 48kHz. thats a
ridiculously dense event stream when most of those ticks have no
significance at all.
event to the TICKS control, with the value being the #
of ticks
(ever-running time or track-time?). Plugins can look at
host->ticks_per_beat.
if you make ticks_per_second constant, then ticks_per_beat is not
constant. if ticks_per_beat is constant, then ticks_per_second is not
constant. computing the number of ticks between two arbitrary times is
(theoretically, at least) quite complex. imagine a situation where a
piece shifts time signatures a few times, has some decelerando and
accelerando sections and a few sudden tempo changes (think prog-rock,
for a start :). how many ticks between a given point in one "section"
and "another" ? if you make ticks_per_beat constant, its easy to
compute the tick count, but hard to compute the interval between
ticks. if you make ticks_per_second constant, its easy to compute
(hah!) the interval between ticks, but knowing how many ticks are
between two musical times is fairly tricky.
* Pre-queuing becomes:
- Plugin: I have an event 100 ticks from now
- Host sends ticks as they happen, even if we loop in time
- Plugin decrements the counter on future events
- If time jumps plugin can discard future events or not, as it wishes
- when the counter hits 0, plugin does whatever
* We can provide SDK code to make this pre-queuing easy.
i like this basic idea, but i don't think that you can send one event
per tick. i think that david is not far from the mark. i think it
should probably work more like this:
Plugin: i have an event at "bar|beat|ticks", what transport
frame is that ... [ computes ].
Host: sends a running audio frame count
Plugin: defines a particular audio frame count as "zero" on
the transport frame scale (e.g. when playback starts),
then executes the event at the correct offset. when
the plugin considers the transport to be not moving,
no events get executed.
something like that.
the hard part here is that plugins needs to be able to share the tempo
map, because they need to be able to look ahead to compute an audio
frame (offset) that corresponds to a given B|b|t time. this is going
to be a critical problem with JACK as well. its all very well saying
that a particular plugin can do this, but if you want several plugins
operating in sync with the same notion of tempo, there needs to be a
way to share the information between them. VST does this in a rather
crude way, JACK currently doesn't do it at all. if you put it in the
host, that helps a lot, but it now requires ways to edit the tempo
map, which would typically be in the domain of a sequencer, and the
vibe here is that the host is not necessarily a sequencer ...
--p