Subject: Re: [linux-audio-dev] XAP and these
> > Plugins can
well, the plugin has to know ticks-per-beat and samples-per-tick. Or
Thinking again: A plugin is really concerned with the past, and how it
> Yes, although sending one event for every tick, assuming that a tick
Do we really need to send tick events EVER? Assuming we like the idea of a
plugin: host->tick_me(100, cookie); /* alert me in 100 ticks */
I guess I don't really like that. I'd rather see:
plugin recognizes the need for some action in 1/4 beat.
This should solve the issue of needing to know the passing of linear musical
This archive was generated by hypermail 2b28
: Fri Dec 13 2002 - 23:18:12 EET
From: Tim Hockin (thockin_AT_hockin.org)
Date: Fri Dec 13 2002 - 23:14:53 EET
> > look at
> > host->ticks_per_beat.
>
> No, that can change at any time (or many times) in the block.
rather, samples-per-beat. If we know samples per beat (tempo) we can do
whatever we need, right?
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?
> 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.
tick:
host delivers a tick event at the right time.
plugin knows there are 18,900 samples per beat (140bpm @ 44.1k)
plugin delivers a long-term event to itself for now+4725 samples
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...