Subject: Re: [linux-audio-dev] XAP and these
>Maybe I don't get all the issues, but the following thoughts occur to me wrt
ardour uses 1920 ticks per beat. if the beat is 180 bpm, that's 5760
>event to the TICKS control, with the value being the # of ticks
if you make ticks_per_second constant, then ticks_per_beat is not
>* Pre-queuing becomes:
i like this basic idea, but i don't think that you can send one event
Plugin: i have an event at "bar|beat|ticks", what transport
something like that.
the hard part here is that plugins needs to be able to share the tempo
--p
This archive was generated by hypermail 2b28
: Fri Dec 13 2002 - 15:03:40 EET
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Fri Dec 13 2002 - 15:04:22 EET
>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)
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.
>(ever-running time or track-time?). Plugins can look at
>host->ticks_per_beat.
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.
> - 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.
per tick. i think that david is not far from the mark. i think it
should probably work more like this:
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.
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 ...