Re: [linux-audio-dev] XAP: a polemic

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Sun Dec 15 2002 - 20:28:53 EET


On Sunday 15 December 2002 07.24, Tim Hockin wrote:
[...]
> Replying to myself with two other ideas:
>
> 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.

(The sort/merge function might be a nice thing to make public,
though, since plugins can make use of it internally for other
reasons. It's just a tool.)

> Again, just blathering. Trying to find something elegant..

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.

//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 ---


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Dec 15 2002 - 20:33:45 EET