[linux-audio-dev] XAP and Event Outputs

David Olofson david at olofson.net
Wed Dec 11 17:10:01 UTC 2002


On Wednesday 11 December 2002 22.26, Tim Goetze wrote:
> David Olofson wrote:
> >> so eventually, you'll need a different event system for
> >> plugins that care about musical time.
> >
> >No. You'll need a different event system for plugins that want to
> >look at future events.
>
> which is an added level of complexity, barring a lot of ways
> to head for plugins.

I don't even think the kind of plugins that would need musical 
timestamps to work at all, would fit very well into an API that's 
designed for block based processing. I'm concerned that merging two 
entirely different ways of thinking about audio and events into one 
will indeed be *more* complex than having two different APIs.

Some people want to keep LADSPA while adding support for XAP. Now, 
are we about to make XAP so complex that we'll need a *third* API, 
just because most synth programmers think XAP is too complex and/or 
expensive?

(Meanwhile, the Bay/Channel/Port thing is considered a big, complex 
mess... *heh*)


> >> i'm convinced it's better to design one system that works
> >> for event-only as well as audio-only plugins and allows for
> >> the mixed case, too. everything else is an arbitrary
> >> limitation of the system's capabilities.
> >
> >So, you want our real time synth + effect API to also be a
> > full-blown off-line music editing plugin API? Do you realize the
> > complexity consequences of such a design choice?
>
> a plugin that is audio only does not need to care, it simply
> asks the host for time conversion when needed. complexity is
> a non-issue here.

But it's going to be at least one host call for every event... Just 
so a few event processors *might* avoid a few similar calls?


> and talking about complexity: two discrete
> systems surely are more complex to implement than one alone.

Yes - but you ignore that just supporting musical time in timestamps 
does not solve the real problems. In fact, some problems even become 
more complicated. (See other post, on transport movements, looping, 
musical time delays etc.)


> i'm becoming tired of discussing this matter. fine by me if
> you can live with a plugin system that goes only half the way
> towards usable event handling.

This is indeed a tiresome thread...

However, I have yet to see *one* valid example of when musical time 
timestamps would help enough to motivate that all other plugins have 
to call the host for every event. (I *did*, however, explain a 
situation where it makes things *worse*.) I have not even seen a 
*hint* towards something that would be *impossible* to do with audio 
time timestamps + host->get_musical_time() or similar.

To me, it still looks like musical time timestamps are just a 
shortcut to make a few plugins slightly easier to code - *not* an 
essential feature.

Prove me wrong, and I'll think of a solution instead of arguing 
against the feature.


//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 -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list