13 Dec
2002
13 Dec
'02
9:51 a.m.
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 ---