18 Dec
2002
18 Dec
'02
4:56 a.m.
On Wednesday 18 December 2002 02.49, Tim Hockin wrote:
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.
Yes... Problem is that if you discard an event that the plugin would
actually want to adjust, it's going to be hard to reevaluate it,
since the data that had you enqueue the event in the first place will
be gone. You'll have to have some place to store the original tick
and some other info...
Anyway, if the host just calls you back, or gives you an event for
each prequeued event that it's about to throw away, it gets easier to
deal with, I think. (Still need somewhere to put your original data
for reevaluation, though.)
- 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 It
just needs to be EASY (e.g. in the SDK).
Yes.
//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 ---