>I'm starting to get a better picture of what I mean. :) The transport >controller manages transport start/stop/pause, playback location, and maybe >shuttle speed. Most plugins won't care about transport state (except maybe >shuttle speed...). So I don't see any reason to disallow it anymore.. notice how JACK's transport API evolved from a single controller for transport and time to one in which they are decoupled. i think there is a message here. >> >I'm sorry I'm being dense on this - can you explain how UTC solves this? I >> >understand about having a neutral high resolution clock, but based on my >> >understanding of UTC (as we have defined it), how does it solve this? >> >> Second that. I'd especially like an explanation of how UTC relates >> to sync across different boxes, word clock across different boxes, >> house sync, and how disagreements among all of the above should be >> resolved. In short: I'm a plug, hey here's an event that has to >> happen at a specific time, but the event has multiple time fields, so >> how do I decide when to use the UTC field vs. when do I use the >> sample frame index field? 1) please stop calling it UTC. UTC is essentially just a timezone label. the acronym is Unadjusted System Time (UST). Unadjusted because it has to be monotonic, which on a system using NTP or that allows the user to set the clock, is not guaranteed. 2) UST does not apply across boxes. 3) to sync any two decoupled streaming media clocks requires a neutral 3rd party. 4) we have so far disavowed network setups, so i am not particularly interested in how we could provide a network equivalent of UST. there are possibilities, but right now they seem beyond the scope of GMPI itself. 5) the UST field has to be provided for *all* events. its a companion to whatever other time(s) is/are provided. it will be used if a plugin wants to sync between that event and some event stamped by a different streaming media clock. --p ---------------------------------------------------------------------- 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