15 Dec
2002
15 Dec
'02
9:51 p.m.
On Monday 16 December 2002 02.01, Tim Hockin wrote:
Ok. So how does a plugin know about musical milestones, then?
Suppose it wants to lock onto a beat edge. I agree that TICKS
events are not needed, since if you know the sample rate (you do)
and you know the tempo (you can), then you can extrapolate a
tick-width.
Synchronizing: Tempo data.
Alt 1: You adjust your internal "tempo" variable whenever
you get a TEMPO Control change. For every sample in
your inner loops, you add that value to your internal
"position" variable. The "position" variable now
corresponds to "free running musical time", tracking
the tempo of the timeline, but not locking to the
position.
Alt 2: Call the host whenever you want the tempo at a
specific position. If you want to know exactly when
tempo changes occur, you'll simply have to ask for
the tempo for each frame in the block, or you need
a more advanced API.
Hmm... If it is, then virtual time is basically the same thing as
audio time, only in a different unit, and not necessarily fixed to
audio time. (Still can't see much point, though.)
//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 -'
--- http://olofson.net --- http://www.reologica.se ---
Standing proposal:
Host processes blocks of 'n' samples. Events are delivered
with a timestamp that says 'actuate this event at this time
within this buffer'. This is exactly what user-supplied
automation is, totally randomly timed events. Some plugins
need to sync to tempo or music-milestones. They indicate this
need and receive tempo, meter, ticks events. It is responsible
for tracking changes.
drop the tick events and it starts to sound reasonable. The tick edge is the trick.
Locking: Positional data.
Alt 1: Maintain sync and local position as described above.
When you get a POSITION_CHANGE Control change, adjust
your "position" to the new value. Now, "position" is
locked to the timeline position.
Alt 2: Call the host whenever you want the musical position
for a specific sample, or (as in VST) get timeinfo
for the first sample in the block, and then ask for
the tempo for each sample frame, to reconstruct the
musical position for the whole block.
All the details of Alt 1 can easilly be wrapped in the plugin SDK, if
people find it complicated enough to motivate it.
Or do we not worry about
it and assume that the user will start things at the proper edge,
and plugins will just need numbers of tick-widths?
No no, that's way to flaky, and would also mean that transport events
(loops, skips, start, stop) cannot be handled at all. You must be
able to resync the position at any time, to any position in the
timeline.
buffer-relative timestamps are a definite no.
Yeah, I didn't mean it to come across that way - we've already
decided that timestamps are continuous. Sorry for the
miscommunication.
I don't get what you were saying about virtual time. Let me try:
frame-count is a global rolling counter. It never stops, unless
the host has a special 'off' mode. Ticks is a mucial counter
starting at some point, 0, that represents the timeline
(track/song/whatever). It can jump forward (12, 13, 165) or
backward (165, 166, 1) or loop, or pause. If it is paused or
stopped, the frame-counter is still going. Since plugins just
track 'ticks' by that, they still work.
Is that correct?