Trying to rationalize the discussions from yesterday, to see where we are. We agreed that there needs to be some fundamental unit and data type for absolute time. (I'll call this data type ABSTIME.) Proposals were to use either: - Samples (as in the system audio sample rate) - "Quanta", ie, an int64 value with a system specified "quanta per second" to determine the rate - Seconds (as a double precision float) A plugin's "process" routine, ie, the function that renders frames of audio, is supplied 2 ABSTIMEs: the stream time for the current frame, and the UST (aka "wall time"), for synchronization. [Brief aside about USTs: I occurred to me that different host platforms will only be able to update UST values at different resolutions. So we probably need a "GetUstResolution" API provided by the host to the plugin.] I think we agreed on at least this much. The other issue discussed was how musical time information gets passed into the plugin. I'll try to synthesize a few possible solutions to this point, for the sake of picking up the discussion again. First, lets assume we'll define a data type for musical time. I'll call it MUSTIME. TBD is whether this time uses bars/beats/ticks, floats, or other. Proposal 1: A plugin's "process" routine is also provided with a MUSTIME value that provides the current musical stream time for the frame. MUSTIME is designed (cleverly<g>) to encode tempo information, so some "MUSTIMEs per ABSTIME" (in this frame) can be computed. Tempo and meter changes are delivered to the plugin "just-in-time", as separate events. Proposal 2: The host provides time conversion routines, to go from ABSTIME to MUSTIME. Implicit in this conversion is the tempo. The host also provides access to tempo and meter information, if it exists. Proposal 3: Events that are delivered to the plugin's "process" routine have unique IDs. The host provides methods to cough up a MUSTIME (and/or ABSTIME?) timestamp for an event, given its ID. ---------------------------------------------------------------------- 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