[gmpi] Re: Topic 6: Time representation



Tim Hockin wrote:
1.) The host defines a quanta which is the smallest time interval allowed in its timing system. This is communicated to the plugin at the time of instantiation, and cannot change for a particular instance of a plugin. The host communicates this using an int64 quanta per second value.


Mike - it seems that we've entered an area not common for audio, so bear
with me:

1) Can you not just increase the sampling rate?

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.



2) how does quanta/sec relate to samples/sec ?  Audio plugins will want to
generate data at the audio sampling rate.  Can we say then that quanta are
really sub-samples, and are defined as sub-samples per sample, with audio
generated at the sample rate?  Pure-audio hosts will set the subsample rate
to 1, and the sample rate to 44100 or 48000 or whatever.

We could do it as two separate rates with a subsample rate, but this is more complicated to me than one quanta which may be smaller than a particular audio quanta.


Let me give another pure audio example. Lets say a host allows audio tracks with different sample rates, 44.1k and 48k. It would want to line up events using a quanta which was an integer multiple of both rates, which is smaller than the quanta for either rate alone. Then a plugin on one track would see and event and naturally quantize it in the following step:

sample position = timestamp / quanta per sample.




Every meter event contains its metrical position and its duration in quanta to the next event. So if you ask for a resolution of 2 and the meter is 3/8, you will receive two meter events, one at the beginning of the measure with a duration of 2 eighth notes (expressed in quanta), and 1 after 2 eighth notes with a duration of 1 eighth note. Therefore all tempo changes are quantized by the host to the resolution requested by the plugin.


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.


--
Mike Berry
Adobe Systems


---------------------------------------------------------------------- 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: