[linux-audio-dev] XAP: a polemic

[Tim Goetze]

Tim Hockin wrote:

>> 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.

to allow for everything you mention here, you need to 
start counting a different time -- you've stopped the
transport, so transport time isn't flowing any more.

at least that's what i do, calling it 'virtual time'.

the thing is that you need to keep time well-defined
and controllable at one point, for the whole network. 
if you don't, things like synchronization and transport 
control are tough to get right.

>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. 

buffer-relative timestamps are a definite no. 

reason: you need to be able to schedule events far 
ahead (streaming, prequeueing). calculating a buffer-
relative time in this case requires either knowing 
all future buffer sizes or updating these events at 
every cycle. the latter is too awkward, and the former
enforces a guarantee that severely limits the system's
synchronization capabilities.

tim