[linux-audio-dev] XAP and these <MEEP> timestamps...
Tim Hockin
thockin at hockin.org
Fri Dec 13 16:21:07 UTC 2002
> > Plugins can
> > look at
> > host->ticks_per_beat.
>
> No, that can change at any time (or many times) in the block.
well, the plugin has to know ticks-per-beat and samples-per-tick. Or
rather, samples-per-beat. If we know samples per beat (tempo) we can do
whatever we need, right?
Thinking again: A plugin is really concerned with the past, and how it
affects the future, not the future alone. plugin: "I received some event
that needs further processing in 1.5 beats". If it knows how many samples
per beat, and it receives tempo-change events, what more does it REALLY
need? We can provide ticks as a higher level of granularity, but is it
really needed?
> 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.
Do we really need to send tick events EVER? Assuming we like the idea of a
tick:
plugin: host->tick_me(100, cookie); /* alert me in 100 ticks */
host delivers a tick event at the right time.
I guess I don't really like that. I'd rather see:
plugin recognizes the need for some action in 1/4 beat.
plugin knows there are 18,900 samples per beat (140bpm @ 44.1k)
plugin delivers a long-term event to itself for now+4725 samples
This should solve the issue of needing to know the passing of linear musical
time. It doesn't solve the need for a plugin to know about looping or
transports in musical time. Does a plugin need to know this? Maybe useful
for it to go to the middle of a sample or something...
More information about the Linux-audio-dev
mailing list