[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