Subject: [linux-audio-dev] supporting LADSPA
From: Kai Vehmanen (k_AT_eca.cx)
Date: Thu Apr 13 2000 - 01:20:04 EEST
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 - 02:23:58 EEST