14 Dec
2002
14 Dec
'02
2:11 a.m.
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 :)