[linux-audio-dev] XAP: a polemic
Tim Hockin
thockin at hockin.org
Tue Dec 17 19:31:00 UTC 2002
> > 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.
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 (unless we change ticks_per_beat dynamically).
> > 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.
Refcounts.
> 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
More information about the Linux-audio-dev
mailing list