> 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 2) plugins that need to do things on tempo milestones - they have a TEMPO and can host callback for music-time 3) plugins that need to do things at some point in absolute time - they have the sample rate, no worries 4) plugins that need to do things at some point in song time - they have a TRANSPORT control > (*) 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... > 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? > Meter changes > When PPQN (who would change *that* in the middle Define PPQN in our terms? Pulses of... Then I can digest the rest of this email :)
