[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 else the plug-in gets events at the musical time interval it likes, ...

..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
        }
}

OK, then you have a position in ticks in a floating point format, which is correct at each sample across the timeslice. Using floating point makes that kinda easy. But why is this important, or rather, what fraction of plug-ins will need to do that? You already have events stapled to index offsets, and could convert the offsets into a ticks-plus-stepped-fraction when you need them, and you could subscribe to events like I describe above if you want sprocket holes. The advantages of floating point musical time are not so great.


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

So sorry! -- I was just saying that I couldn't comment on what you'd said because it's such a tiny part of the whole, and I was asking you to answer some questions so that I could respond. Some of which you've just done, thanks.


> 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.

Yeah, I agree.


> 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.

Yeah, that was pretty far-sub. I think we'll need something sub, but still need to look closer. I.e., is common-multiple-of-44100-and-48000 the only answer? What if the system is operating with pull-down or pull-up, so you've got to work with, like 44050 and 48000? What about the future when we have sample rates like more 120 kHz? Then the LCMs can get pretty big. Do we need a fractional value? Etc. etc.

-- Chris

----------------------------------------------------------------------
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: