> Well, since I am talking about a vested interest here, let me explain. > In an audio/video editor, you always have to frame rates (A and V) in > your timeline. In order to choose a time quanta that evenly divides into > both, audio sample rates are not sufficient. For example, take NTSC > Digital Video with a video rate of 30000 / 1001 and a audio sample rate > of 48000. My time quanta needs to be a number like 1441440000 quanta per > second. Ok, I can buy the need for this. Since this is supposed to be an audio API, I would suggest that we define the audio sample rate and the sub-sample rate as sub-samples per sample. Objections? > > I don't get this. How does the host know how to quantize like this. > > Better, perhaps to just get a BEAT event and subdivide that internally. But > > if plugins start relying on this, then we have to assume we send meter > > events when the transport is stopped, which is weird.. > > > > The meter events would only flow while transport was not stopped. The > host knows its timeline. So it knows how to calculate the exact position > in quanta of any event, after taking into account tempo changes. So > every meter event simply contains a duration, which is the delta in time > before the host is going to send the next meter event. I still don't get the point of this. Or how the host knows to quantize a 3/4 bar into 2+1 and not 1+2. ---------------------------------------------------------------------- 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