17 Dec
2002
17 Dec
'02
9:54 p.m.
- 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)
Yes. My argument againt building it into the host:
What do you do with events that "fall outside" as a result of an
"unexpected" event? Throw them away? (And leave hanging notes.)
Squeeze them in? (And trig something out of sync.) Squeeze them in,
but align them to some note value?
The plugin most probably knows, or the user can tell it what's best
Well, if this is really important, perhaps something to the effect of
host->abs_scrow(plugin, tick_num, event_queue, value);
The plugin requests that the host deliver an event to the particular queue
when we hit a specific abolute tick time (host turns it into audio time for
event delivery, of course). If the transport jumps (i.e. a loop) the escrow
is discarded. Plugins can do this on their own and just observe TRANSPORT
events, too. It just needs to be EASY (e.g. in the SDK).
something that you can wrap in a trivial
"host->enqueue_event()"
call. If a generic implementation is at all useful, it should be an
optional part of the plugin SDK.
right.