[linux-audio-dev] XAP and these <MEEP> timestamps...

David Olofson david at olofson.net
Fri Dec 13 08:52:00 UTC 2002


On Friday 13 December 2002 10.11, Tim Hockin wrote:
> 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).

Yes, that's an easier and much more robust way of doing it.

As soon as ask for absolute musical time, you ask for trouble - and 
you *have* to deal with it, or Bad Things will happen as soon as 
people use your plugins together with loops, conditional jumps in 
interactive scores and that kind of stuff.


> * What if plugins that care about musical time have a TICKS
> control. Whenever the host crosses a tick boundary, it sends a
> (sample-accurate) event to the TICKS control, with the value being
> the # of ticks (ever-running time or track-time?).

Maybe... It's not perfect, though, but if you count ticks *and* keep 
track of tempo change events, you *can* actually maintain your own, 
exact copy of the timeline, in whatever format you like.

And, of course, this works even when you get input from different 
timelines on different channels.


>  Plugins can
> look at
> host->ticks_per_beat.

No, that can change at any time (or many times) in the block.


> That, combined with a TEMPO control should
> allow the plugins that care to access musical time without host
> callbacks and without impacting the fast path.

Yes. Plugin SDK macros can be provided to implement this in one or 
two generally useful ways, if that makes sense.


> * 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

Yes, although sending one event for every tick, assuming that a tick 
is the smallest time unit that the sequencer knows about, means that 
you get lots of tick events, or that you need to do some extra work 
in plugins, to calculate the ticks that don't come in as events.

Right; plugins that listen only to ticks when they actually come 
probably aren't interested in sub-tick accuracy anyway. Plugins that 
*are* will work fine regardless of tick resolution, since they need 
to generate a full sample frame rate model of the timeline internally 
anyway.

This should work.


> * We can provide SDK code to make this pre-queuing easy.

Yes; a "mini sequencer toolkit", basically.


> Just late night blathering.  Tell me if I am an idiot (and
> preferably what about :)...

Well, you seem to have solved the problem with multiple timelines in 
the same net. You can have one per Channel this way. :-)


> I'm sure I'll have a slew of emails when I wake up, I always do.

*hehe*


//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 -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list