[gmpi] Re: Topic 6: Time representation

> >A process block may be
> >smaller than a tick.  You need to keep track of current_tick + some delta
> >until the next tick.
> 
> Er, can you spell out 'might have to deal with them' and 'need to 
> keep track of'? And which context(s) you're talking about (see list 

Assuming a plugin gets the transport position at some point (maybe 0)
Assuming a plugin cares about edge detection of bars, beats, or ticks
We either send an event for EVERY tick, or the plugin can track it:

double pos_in_ticks;
double ticks_per_sample;

process() {
        ...
        for each sample in this block {
                ...
                pos_in_ticks += ticks_per_sample
        }
}

I'm not actually sure what we're debating here.  Can you clue me in?

> again, below)?  Also, are you assuming that music events and 
> interesting-musical-time events both arrive at the plug-in with hard, 
> sample-based times?  How is the plug-in getting tempo, via a 
> parameter?  All these things have to be designed to work together, 
> and I'm not sure which approach you're suggesting for some of the 
> elements.

I'd like to see EVERYTHING (or almost everything) come in as
hard-timestamped events.  Tempo changes, meter changes, everything.

> OK, there's a requirements issue we should look at:  Does GMPI need 
> to support sub-sample event timing accuracy?  If so , how far-sub?

I think Mike Berry made a pretty good case for it.

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: