Subject: Re: [linux-audio-dev] supporting LADSPA
From: David Benson (daveb_AT_idealab.com)
Date: Thu Apr 13 2000 - 02:54:39 EEST
Ok, GDAM also now supports LADSPA too.
It autogenerates guis using all available hints.
The primary annoyance was that in order to present a
convenient list of LADSPA plugins (in an efficient amount of time)
I had to write a program which scans the common directories
and outputs which plugins by name are in each module.
[Currently you have to add each filter in by hand actually...
but that'll change tonight, hopefully for the daily build
tomorrow]
Oh well, not a big deal -- but it would be nice if hosts
could share that data. [also, then installing ladspa plugins
could be a bit more convenient and standard from host-to-host]
I may just break down and have gdam scan them all on startup.
Sounds potentially too slow though, if you had lots of plugins.
The real excitement is forthcoming though -- I realized
that using the graphical filter designer embedded
in gdam's `mini network', I can make
xml that specifies a ladspa filter. I am writing a program
that will convert that xml to ladspa plugins (ie generate c code).
I am mostly done, but there may be a little testing to do :)
Furthermore it will be separate from GDAM, so that
conceivable you could write other guis, or, with difficultly,
craft the xml by hand.
If you have any suggestions on such a project,
or want to help, you are more than welcome.
I'll post again when I get done :)
- Dave Benson
On Thu, 13 Apr 2000, Kai Vehmanen wrote:
> Ok, it seems that there aren't any serious problems with the current
> LADSPA API. Memory handling and GUI issues seem to be the most problematic
> areas. However, both are something that can be added later (MuCoS,
> LADSPA-v2, etc). Both are also rather complicated additions, and
> will take quite a bit of time to implement.
>
> As for GUI issues, you can always use the hint-information
> to generate a generic GUI. Not perfect, but works.
>
> Quoting David:
> > 2. I would just have to reimplement the specialized
> > tracker features on top of LADSPA
>
> If the surrounding environment is more complex than LADSPA, then it's
> better to just write a wrapper. You said that Buzz supports VST -> I see
> no reason why Octal couldn't support LADSPA. Same goes for GLAME. In most
> cases, replacing app's native plugin API with LASDPA is probably
> impossible... but IHMO this isn't that big of a problem.
>
> In libecasound, I've written a wrapper class for LASDPA. Other parts of
> the library see LADSPA plugins as normal ecasound effects.
> Multiple-channels are handled by creating multiple plugin instances (one
> LADSPA-plugin per channel), all inside the class. Libqtecasound, offers a
> simple LADSPA-GUI (Qt-based, plugin selection + configuration). I've just
> released new devel-versions of ecasound (1.7.5d11) and ecawave (0.2.0d11).
> Both support LADSPA-v1.
>
> But, but, now we need more plugins and more host implementations.
> As long as we only have LASDPA-SDK + my ecasound packages, it's
> quite impossible to promote LADPSA.
>
> --
> Kai Vehmanen <k_AT_eca.cx> ---------------- CS, University of Turku .
> . audio software for linux ... http://www.eca.cx .
> . armchair-tunes mp3/wav/ra .. http://www.wakkanet.fi/sculpcave .
>
>
>
This archive was generated by hypermail 2b28 : Thu Apr 13 2000 - 03:32:41 EEST