> - The host defines a int64 ticks per sample which is guaranteed to be > constant during runtime. now you lost me - ticks per sample? So we're designing in sub-sample accurate timing? > - There are only two kinds of time, absolute and transport. All times > are passed as both. For hosts with no transport, the values are always > identical. I agree that there are two (well, three if you count UST) fundamental times. However I see it as: timestamps: integral samples since time-0 position: real ticks since play-position-0 > I don't see any reason to make it more complex than this. Time to And I say the same. In the XAP model, there are a few given values which a plugin can be notified of: Given: freq: samples/sec timebase: ticks/beat tempo: ticks/sec meter: ticks/measure meterbase: beats/whole-note position: ticks From those values we can get at just about anything: Derive: beats/measure: meter/timebase beats/min: tempo/timebase * 60 samples/tick: freq/tempo And we can also think about synchronization events from host: beat edge (with sample timestamp) measure edge (with sample timestamp) tick edge (with sample timestamp, but ick) As well as a maybe informational callbacks: get current bar:beat value In fact, we can do edge-detection without further help, really: beat edge: ((int)(pos*100) % (timebase*100)) == 0 bar edge: ((int)(pos*100) % (meter*100)) == 0 tick edge: ((int)(pos*100) % 100) == 0 ---------------------------------------------------------------------- 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: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe