Subject: Re: [linux-audio-dev] XAP and these
On Friday 13 December 2002 14.04, Paul Davis wrote:
Yeah, that's what I'm thinking. One should probably only send the
> >event to the TICKS control, with the value being the # of ticks
Think, *any* kind of music, practically. Slight tempo changes during
> how many ticks between a
Right. This is why you always have to think in term of a timeline as
> >* Pre-queuing becomes:
Yeah, that's basically it. The important thing to keep in mind is
> the hard part here is that plugins needs to be able to share the
Actually, they only really need to know whether that time is inside
So, what you need is the part of the timeline corresponding to the
> this
And if you have plugins working with a few *different* timelines,
> VST
Right... I've been thinking of implementing tempo maps as separate
Tick events, tempo change events and transport events would "work",
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
This archive was generated by hypermail 2b28
: Fri Dec 13 2002 - 16:52:31 EET
From: David Olofson (david_AT_olofson.net)
Date: Fri Dec 13 2002 - 16:38:48 EET
> >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.
first tick of each block, and the first tick after a tempo change. If
even that.
> >(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 :).
verse or chorus, tempo ramping during breaks and that kind of stuff
is every now and then, even in normal pop music. It's just subtle
enough that most people won't notice until you tell them! :-) (That's
why it works; you're not *supposed* to conciously notice it.)
> 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.
either an abstract non-linear function, or a list of ranges;
potentially more than one per sample frame. If you want to be
absolutely correct, you cannot get around this.
> > - 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.
that you cannot trust anything said about the time beyond the end of
the current block, and that you cannot assume anything about the part
of the timeline that's inside the current block - it can be
non-linear, contain skips or whatever.
> 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.
the current block or not. If it's before, it's already too late (all
you can do is try to hide the mistake...), and if it's in the future,
you're strictly speaking not allowed to care, since *no one* knows
what will actually happen. You'll have to wait until the event is
inside the block - if that ever happens, that is.
current block.
> 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.
you'll also need a way to tell which one to look at.
> 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 ...
plugins, that driver both sequencers and synths. Either way; same
problem - plugins need a way to export timeline data so that other
plugins can access it.
but it's extremely inefficient for high tick resolutions, obviously.
*heh*
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---