[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Tue Dec 17 20:14:01 UTC 2002


On Wednesday 18 December 2002 01.25, Tim Hockin wrote:
> > > 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

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


> (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.
>
> 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.


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

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.


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

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.


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



More information about the Linux-audio-dev mailing list