11 Dec
2002
11 Dec
'02
6:09 p.m.
On Wednesday 11 December 2002 22.26, Tim Goetze wrote:
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?
David Olofson wrote:
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*)
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. 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? 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 ---