>>> Personally, I would prefer to see tempo specified as a list of timestamped "tempo events" for that buffer (the way MIDI events are in dealt with in VST). The plugin can then perform sample accurate event handling for that buffer. <<< I don't think tempos can be events. Here's why I believe this, please explain why I'm off base about this. Each processing frame is given as a fixed size, in samples. We're saying that events for a frame are passed in just before the frame is to be processed, In other words, conceptually the plugin gets 2 delivery "packets" in every "duty cycle": events, then audio buffers. Events are stipulated to be live within the audio frame. We talked about disallowing events to be delivered for future times. Let's say for arguments sake our audio frame size is equal to 1 beat = 960 ticks (assuming MIDI parlance for a second) at whatever the current tempo is. Every set of events that are passed in live within the next beat, and can be safely rendered in the next beat-sized frame. Now I allow a tempo event to come in. This event slows the tempo down, so that one audio frame is now equal in duration to 1/2 a beat or 480 ticks. If the host is feeding these events to the plugin, the host now needs to be careful about what events get sent after the tempo change, to ensure that we don't send more events than fit in a single frame. If a plugin is sending these events to other plugins, how do the other events in the other plugins "know" that they are now out of range for the audio frame? ---------------------------------------------------------------------- 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