Subject: Re: [linux-audio-dev] XAP and these
On Saturday 14 December 2002 07.05, Tim Hockin wrote:
Yes.
> 2) plugins that need to do things on tempo milestones
Yes - except that the host can't know which timeline you're asking
> 3) plugins that need to do things at some point in absolute time
Right.
> 4) plugins that need to do things at some point in song time
Yes.
> > (*) You *really* don't want two events with the same timestamp,
Exactly. That's why we use the alternative logic: The current tempo
> > Tempo changes
Could be any handy unit, as long as it's tied to a timeline, rather
> > Meter changes
Pulses Per Quarter Note. Let's simply set that to one, and forget
> Then I can digest the rest of this email :)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
This archive was generated by hypermail 2b28
: Sat Dec 14 2002 - 16:24:43 EET
From: David Olofson (david_AT_olofson.net)
Date: Sat Dec 14 2002 - 16:19:14 EET
> > 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
> - they have a TEMPO and can host callback for music-time
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.)
> - they have the sample rate, no worries
> - they have a TRANSPORT control
> > where the first says "tempo=-Inf" and the other says
> > "tempo=120 BPM". But that would be the closest to the correct
>
> ick...
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.
> > 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?
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!
> > When PPQN (who would change *that* in the middle
>
> Define PPQN in our terms? Pulses of...
about it. We don't want plugins to keep track of some arbitrary
conversion factor, that is in fact entirely irrelevant.
| 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 ---