Re: [linux-audio-dev] Linux Audio plugin API's: where are we ?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Linux Audio plugin API's: where are we ?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Apr 06 2000 - 17:58:44 EEST


>Btw. the more relevant intend of my (GLAME) reply was to stress that
>GLAME will not switch to be a LADSPA host, i.e. it will keep its
>special plugin interface. I suspect this is true for other projects,
>too - so the point of having LADSPA is to write plugins that run
>(inferior) on all hosts? This doesnt sound that interesting, though.

So what do you suggest as the alternative ? That everyone writes
plugins using a dozen different APIs ? That nobody writes plugins at
all, but duplicates the work that other people have already put in ?

Plugins in the windows/macos world have created a genuinely thriving
and useful environment for audio and MIDI work. This hasn't happened
because of Cubase or Logic or Cakewalk, though they are all nice
programs in their own ways, but because of their plugin API's being
widely adopted by 3rd party developers.

Look, there are two parts to any decent audio environment on a
computer. One of them is big chunk of GUI code that lets you
manipulate the internals, and the other is the internals itself. If
everyone takes the path that you're suggesting (assuming I'm not
misinterpreting your message), we end up with not only multiple GUI
systems (which is just fine), but loads of duplicated code (and
duplicated bugs).

This kind of attitude, which I hear as "plugin API X is technically
superior to plugin API Y, so we're sticking with it", is fine if you
*all* want to care about is the technical superiority of your
code. Most of the time, that *is* all I want to care about. But some
of the time, I want to be able to use other cool stuff *without*
having to reimplement it myself. And if every audio project on Linux
has developers who are convinced (and perhaps rightly so) that their
particular internal design is superior to a common denominator, then
this ability to share other people's work without a lot of work on my
part is never going to happen.

I think that this would be sad.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Apr 06 2000 - 20:08:20 EEST