> -----Original Message----- > From: Tim Hockin [mailto:thockin@xxxxxxxxxx] > Sent: 16 February 2004 21:12 > To: gmpi@xxxxxxxxxxxxx > Subject: [gmpi] Re: 3.9 Time Formats > > I can't see how a 'full tempo map' can exist in a realtime setting. Well it can't, can it ! However we are actually talking about at least 4 use cases as far as the end user is concerned: 1: Bounce down (or off line processing). Here the tempo map of the host is set in stone, from start to end. A plugin can look at any point in the tempo map safe in the knowledge that it won't change. 2: User editing. Here the user is playing through a project, the tempo map is set, but there is a chance that the user may change it during the edit. I expect any user would accept that such an action, with a tempo aware plugin in place, may have unintended consequences. If the user makes the edit, rewinds the transport and hits play then the plugin will behave as it should 3: Live input. Here, in a live performance the user is altering the tempo in real time. There is no tempo map to speak of and a request for a tempo for a future time is meaningless. The safest thing for the host to do would be to return an error or "not meaningful" condition. It would be up to the plugin to decide what it should do, use the current tempo, stop tempo synch, warn the user ? 4: The plugin is in a rewired slave. Again the plugin will not have access to the tempo map. This should be the same as 3 for the plugin. However the user has the opportunity to move the plugin to the rewire host (providing it's not itself being used "live"). By not allowing a plugin to have access to the tempo map in use cases 1 and 2 we will be restricting plugin developers, and may be restricting some innovative ideas. The users should be aware however that "unexpected" results would occur if the plugin is used "live" Personally I'm for allowing the plugin access to the full tempo map (conditions 1+2) but allow for an error condition to occur if the host doesn't itself have access to the tempo (condition 3 and possibly 4). Andy ---------------------------------------------------------------------- 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