17 Dec
2002
17 Dec
'02
8:30 p.m.
1) the
host->tick_me(plugin, 100, cookie) // call me back in 100
ticks - This could be a simple host-based time-management API
- This depends on a 1-1 map between host and timeline, which I
think is ok
Yes... It's just that it's not very useful if you get a tempo change
before that tick. How is the host supposed to know what to do? It
doesn't know what you're doing, so there's no single correct answer. 2) rather than
having per-channel TEMPO etc controls, have a small
set of host-global (timeline global, if you prefer to say) event
queues. If a channel is concerned with TEMPO, they will have
already gotten the hosts TEMPO queue. They can then check it.
This saves delivering the same event struct to potentially many
plugins, and still is sample accurate.
This won't work, since you can't check an event queue that you do not
own, without a whole set of special macros. The normal event handling
is based on the idea that events you read are meant for *you*, and
that you're supposed to reuse or dispose of the structs once you've
handled the events. Besides, if you somehow read these events from some
global queue,
you'll have to copy and sort/merge them into your real event queue
anyway, or you wouldn't be able to handle timeline events with sample
accurate timing. I strongly believe that plugins should never be
*forced* to do this sort of stuff.
Any plugin that has more than one queue has to do this...
Well, I think the most elegant solution is to base
this on the
standard event + control layer, as far as possible. Anything else
will just result in more special cases and more restrictions (or more
complexity), for no advantage.
As long as it does not need to be special cased, I can buy this. Our notion
of 'hints' has gotten pretty strange though.
(I'm starting to re-read this thread a few dozen messages back, for context)
Tim