Subject: Re: [linux-audio-dev] latest news: the editor taketh shape
From: douglas irving repetto (douglas_AT_music.columbia.edu)
Date: Tue Oct 24 2000 - 03:55:58 EEST
On Tue, 24 Oct 2000, Kai Vehmanen wrote:
> So you can't write a fade-in effect as a LADSPA plugin, what's the big
> deal!? You can still write n+1 different effects as LADSPA plugins and you
> can use them in Ardour without problems. LADSPA was _not_ designed to
> handle all processing needs and requirements. This design decision was
> made for a reason. However, the LADSPA API does cover many cases. If all
> app developers just say "oh, the API doesn't cover x, I'll use another
> API", nobody is going to use LADSPA. And especially, if a high-profile
> linux audio app like Ardour does not support LADSPA... oh, well.
>
> And btw; I'm still uncertain whether we can distribute VST headers with
> GPL'ed software.
for me at least, the issue is that there's a rather large class of plugins
that i'm interested in that "need to know the future", as i think richard
furse said, and those plugins are not possible with the current api
(fade-in is a trivial example, it just happens to be the one that i
started with and that tripped me up).
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 to keep switching between apis depending on the algorithms used in my
plugins!
as i said before, i wasn't around when LADSPA was being developed, so i
don't claim to know the who/what/where/when/why of the design
decisions, and i do understand that LADSPA _was_ designed, and that there
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
usable for the sorts of plugins i'm talking about, then where does that
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
and non-streaming plugins are certainly more alike than they are
different. and as i mentioned above, i can't imagine many people getting
excited about having to switch apis just because their plugin does or
doesn't need to know in advance how many samples it will be operating on!
douglas
This archive was generated by hypermail 2b28 : Tue Oct 24 2000 - 04:34:43 EEST