[gmpi] Re: Topic 6: Time representation

>       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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: