16 Dec
2002
16 Dec
'02
9:26 a.m.
On Mon, Dec 16, 2002 at 01:43:03AM +0100, Tim Goetze wrote:
I thought the assumption was to send only events scheduled for the block te
be processed. If that is the case all tempo based, musical time references
can be converted into sample relative time (eg. sample number within the
block). If the block is to be rendered; it's too late make changes. Block
sizes[1] determine your latency.
If you are scheduling events ahead of the buffer, a few interesting things
happen:
- the plugin needs to have some events queued in musical time reference
(tick) to be able to anticipate tempo changes no known at the time the event
was scheduled (eg. for synching he position)
- In case of real-time changes to the song, events would need to be
adjusted/deleted/inserted. This is something better handled at the
sequencer host
- In case of repositioning, skipping, reversing and other things a user can
do with her jog dial, the queue needs to be adjusted appopriate. Same as
#2
My votes for normalising event timestamps to buffer relative sample
position.
Perhaps a callback to get the actual tempo etc info from the host for those
plugins that require it (say: tempo delay) would be the best solution.
Frank.
[1] - in case of lots of blocks in series; the latency might end up being
quite substantial, or am I overlooking something? If this is true, a setup
(I compare it to my mixing desk with some outboard processors) with varying
number of plugings for every channel would have different latency for
differenct channels.
--
+---- --- -- - - - -
| Frank van de Pol -o) A-L-S-A
| FvdPol(a)home.nl /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
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.