[gmpi] Re: Topic 6: Time representation

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

? clarify?

> >             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 get what you're saying now.  Plug says 'tell me every N ticks', and host
does.  It solves edge detection, and eliminates the need for the plugin to
track pos.  Storing fractional ticks can be left to the plugin.

I rather like it.

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

I think the sample_rate * subsample_rate idea is flexible enough to answer
all that for all hosts, and 64 bits should still be enough for a while :)

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