Subject: Re: [linux-audio-dev] latest news: the editor taketh shape
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Tue Oct 24 2000 - 10:58:11 EEST
On Mon, 23 Oct 2000, douglas irving repetto wrote:
> i agree that no api will cover all cases. but if one api covers x, and
> another covers both x and y, and i'm interested in working on both x and
> y, then clearly the 2nd api wins. using two different apis for plugins
> that do the same general thing (operate on audio data) seems like a bad
> idea, for many reasons. you seem to be advocating the use of LADSPA for
> the things it's good at and some other api for the things it's not good
> at. but for me at least, i just don't see that happening. i don't want to
Have you noticed that there aren't any other APIs around? We started
talking about LADSPA (Sep-Oct 1999), because there was _very_ limited code
reuse (and co-operation in general) between Linux audio apps. The same
delay effect was reimplemented hundreds of times, in each and every
softsynth, mp3-player, whatever project. So we started talking about a
plugin API. Very soon it came apparent, that designing an API that would
be good enough for all of us, would take infinite amount of time. I'm
quite sure, if it weren't for Richard Furse (he summed up our discussions
and came up with a real proposal --> LADSPA), we'd still be arguing about
details.
So no, I'm not at all happy if we now dump LADSPA and start the ever
lasting discussions again. If this has to be done, please extend
the current API instead of reinventing the whole wheel.
> are good reasons for its current state. but it does seem curious to be
> against accomodating what seems to me to be a very reasonable and useful
> extension to the api. if it does turn out that LADSPA isn't and won't be
Ok, here's a short list extensions that were presented with
same kind of reasoning (needed, easy to add):
- dynamic typing (not only floats)
- event system (for sample-accurate control)
- host-provided memory handling (to allow LADSPA plugins to be
used in hard-realtime plugin hosts)
- batch support
- GUI extensions
- list goes on...
It's just a fact that app developers concentrate on their own projects and
their needs, and don't have _that_ much time to spend on API issues. And
another fact is that designing a good API is far from an easy task. Just
look at the current ALSA APIs, and how much work has gone to designing
them.
> leave people who want to do future time-based plugins? do we develop a
> second api for those plugins? that seems silly when the needs of streaming
I understand your point. IMO it would be better if we just extended
LADSPA.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
This archive was generated by hypermail 2b28 : Tue Oct 24 2000 - 11:51:08 EEST