Subject: Re: [linux-audio-dev] XAP and these
On Friday 13 December 2002 10.11, Tim Hockin wrote:
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
> * What if plugins that care about musical time have a TICKS
Maybe... It's not perfect, though, but if you count ticks *and* keep
And, of course, this works even when you get input from different
> Plugins can
No, that can change at any time (or many times) in the block.
> That, combined with a TEMPO control should
Yes. Plugin SDK macros can be provided to implement this in one or
> * Pre-queuing becomes:
Yes, although sending one event for every tick, assuming that a tick
Right; plugins that listen only to ticks when they actually come
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
Well, you seem to have solved the problem with multiple timelines in
> 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! --------------------------------.
This archive was generated by hypermail 2b28
: Fri Dec 13 2002 - 15:51:13 EET
From: David Olofson (david_AT_olofson.net)
Date: Fri Dec 13 2002 - 15:46:24 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).
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.
> 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?).
track of tempo change events, you *can* actually maintain your own,
exact copy of the timeline, in whatever format you like.
timelines on different channels.
> look at
> host->ticks_per_beat.
> allow the plugins that care to access musical time without host
> callbacks and without impacting the fast path.
two generally useful ways, if that makes sense.
> - 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
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.
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.
> preferably what about :)...
the same net. You can have one per Channel this way. :-)
| 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 ---