[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