Subject: Re: [linux-audio-dev] XAP and Event Outputs
From: David Olofson (david_AT_olofson.net)
Date: Thu Dec 12 2002 - 00:04:42 EET
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 ---
This archive was generated by hypermail 2b28 : Thu Dec 12 2002 - 00:10:31 EET