15 Dec
2002
15 Dec
'02
6:47 p.m.
by definition, time isn't flowing when the
transport is
stopped. a delay in stationary time can only be a zero
umm, I know that a requirement for me is to be able to stop the sequencer,
and still play MIDI and have delay lines etc still delay. Are you saying
that this can't be done in your model? In my opinion just because transport
has stopped does NOT mean time has stopped. On the contrary, ticks are
still happening, the tempo is still in effect. Just because the SEQUENCER
stopped sending events doesn't mean the rest of the studio did.
Perhaps it's the loud music last night (anyone ever sen S.U.N. Project -
WOW!), but I just can't wrap my head around what you're arguing.
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.
Alternative proposal:
Host processes blocks of 1 tick. Events are delivered with a timestamp
that says 'actuate this event at this fractional-ticks offset within this
buffer'. This is what tempo-synced plugins want. All other plugins, which
have user-supplied data must translate fractional ticks into sample count
to process events, or events can ONLY occur at tick boundaries.
Tempo/meter/etc are exclusively the host's problem. Converting to samples
is the plugin's problem.
Is that accurate?
Tim