[linux-audio-dev] XAP and these <MEEP> timestamps...

[David Olofson]

On Saturday 14 December 2002 07.05, Tim Hockin wrote:
> > Yes - as long as the song position doesn't skip, because that
> > won't (*) result in tempo events. Plugins that *lock* (rather
> > than just sync) must also be informed of any discontinuities in
> > the timeline, such as skips or loops.
>
> OK, it took me a bit to grok this.  We have four temporal concerns:
>
> 1) plugins that need to do things in step with the tempo
>    - they have a TEMPO control

Yes.


> 2) plugins that need to do things on tempo milestones
>    - they have a TEMPO and can host callback for music-time

Yes - except that the host can't know which timeline you're asking 
about... (Irrelevant to VST, since you simply cannot have more than 
one timeline, unless you split the not in partitions belonging to 
different timelines. There's no way to have musical time related 
input from two timelines to one plugin.)


> 3) plugins that need to do things at some point in absolute time
>    - they have the sample rate, no worries

Right.


> 4) plugins that need to do things at some point in song time
>    - they have a TRANSPORT control

Yes.


> > (*) You *really* don't want two events with the same timestamp,
> >     where the first says "tempo=-Inf" and the other says
> >     "tempo=120 BPM". But that would be the closest to the correct
>
> ick...

Exactly. That's why we use the alternative logic: The current tempo 
is whatever the value of the tempo control is in the timeline at the 
current position. We don't care whether musical time is stopped, 
skipping or whatever; tempo is just a control value.


> > 	Tempo changes
> > 		Whenever the tempo changes, you get a sample
> > 		accurate event with the new tempo.
> >
> > 		Unit: Ticks/sample
>
> Before I go any further: What's a tick?

Could be any handy unit, as long as it's tied to a timeline, rather 
than free running time. I definitely vote for 1 PPQN (ie one tick per 
beat), which is what VST is using. No need to throw PPNQ resolution 
in the mix when we're dealing with floating point anyway!


> > 	Meter changes
> > 		When PPQN (who would change *that* in the middle
>
> Define PPQN in our terms?  Pulses of...

Pulses Per Quarter Note. Let's simply set that to one, and forget 
about it. We don't want plugins to keep track of some arbitrary 
conversion factor, that is in fact entirely irrelevant.


> Then I can digest the rest of this email :)


//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://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---