17 Dec
2002
17 Dec
'02
9:13 p.m.
On Wednesday 18 December 2002 01.25, Tim Hockin wrote:
ticks - if the tempo changes, ticks get longer/shorter but 100
ticks is still 100 ticks. And 100 ticks is a measurement of
musical time that is the same regardless of tempo
Yeah, you're right.
Doesn't work for *position* changes, though, which is what I was
really thinking about. If it turns out that you just missed the
event, should it be thrown away, kept indefinitely, adjusted to the
start of the current block, or quantized to the first beat (or
whatever) in the current block, or later blocks, or what?
I guess you could set up callbacks that let you decide...
Refcounts.
Sounds like great fun in conjunction with sorted, linked lists of
events. :-)
Sure, it's possible to do this with or without refcounts. (Refcounts
would be overkill in this case.) Still doesn't reduce overhead in any
way for most plugins.
Nope, only the ones with rather weird internals. Most plugins will
just have one event queue for each Channel - and that means you get
timeline events right into each Queue.
However, if you don't want to support independent timelines for
Channels, you can just make your timeline controls master controls,
and do whatever you like internally.
Hmm... Yes. What *are* they, actually? Do we need type hints as well
as other hints? Multiple hints per control?
Either way, *datatype* is hard, and simply must be there. The few
timeline events that don't fit in will have their own types. These
events aren't really usable as normal controls anyway, so it doesn't
really matter. All the host has to do is check type compatibility
(input->type == output->type) and then connect as usual.
Only Audio ports are special, and that's just because their buffers
are managed directly by the host.
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. (unless we change
ticks_per_beat dynamically).
No way! :-) It's 1920 (or an even bigger "magic" number), and there's
no need to ever change it.
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
Some catching up to do...? ;-)
//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 ---