[gmpi] Re: Topic 6: Time representation
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 13 May 2003 00:35:09 +0200
On Monday 12 May 2003 23.36, Mike Berry wrote:
[...]
> There is one other pro for a host-defined quanta which could be
> sub-sample but is guaranteed to be audio sample aligned:
> storing/loading of events across sample rates. If the host chooses
> a quanta which is a multiple of all of the audio sample rates that
> it supports, then the time value representing 1 second is identical
> in all of the audio sample rates. If we simply use audio samples,
> then you have a different value for 1 second depending upon the
> sample rate.
I don't think the events sent to plugins should be designed to also
serve as "sequencer events". Those are highly application dependent
things, and most importantly, they're related to a timeline rather
than a running clock such as audio samples. Unless you shut down the
audio engine when stopping the transport, you'll have to offset the
timestamps of the stored events whenever you start, stop, loop or
otherwise mess with the transport. Add external sync, and you're all
the way back at square one, with a rather complex relation between
timeline and audio timestamps.
In short, I think this is useful only in a few, rather special cases.
> Anyway, I could live with times in audio samples, and so far am
> the only one strongly supporting a host-defined quanta (of course
> there haven't been mnay other host manufacturers chiming in :). I
> think it makes some things in the host more complex, but it does
> make some things in the plugin less complex.
Yeah... Although it doesn't seem all that complex to use quanta based
timestamps in the sequencer and just convert them into whatever we
decide on while you're converting sequencer events into control
events. Audio/MIDI sequencers have to do that all the time, or
there's no way they can handle external sync, or even a traditional
musical timeline.
The only problem I can see is what I've mentioned before; losing
accuracy when recording the output from an event processor. I've
already concluded I don't think this is a real problem. Besides, I
suspect that this will happen either way in many plugins, especially
those that also process audio. If they round or truncate, you get the
same result as with sample accurate timestamps.
> What I could not live
> with are any representations that are not always sample aligned,
> including floating point and arbitrary fixed point systems tied to
> seconds.
Why? (I agree, but I'm interested in your motivation.)
> And I think that an arbitrary subsample definition, like
> 60.4 in samples, provides none of the benefits I am looking for and
> just adds complexity.
Well, I consider that relevant only if we actually want to be able to
deliver events with sub-sample accurate timing. Otherwise we should
just use integer sample counts.
BTW, just thought of an application that requires sub-sample accurate
timing: BLIT oscillator or granular synth implemented as one event
generator plugin and an impulse/granule player. (You need sub-sample
accurate timing to keep the rounding errors from messing up the
waveforms, especially at high frequencies.) The interesting part is
that you can throw in various event processors in between the
generator and the player. You could also record the generator output
and mess with it in the sequencer, and then play it back by piping
the events directly to the player. Somewhere in between event and
audio editing...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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
Other related posts:
