[linux-audio-dev] processing plugin standard wrapper

Stefano D'Angelo zanga.mail at gmail.com
Wed Feb 14 09:21:26 UTC 2007


Hi,
Leonard, I know what you mean, for me it would be easier too to just
learn one, pick it up, let go the others and not creating much more
confusion with a wrapper.
I perfectly understand also that wrappers usually add unneeded
complexity, which is obviously the worst thing to do, especially with
pieces of code that should run at real-time.

I don't think I'm a great programmer or a genius with incredible ideas
in mind I'm quite young and inexperienced, and that's why I'm here.
However I'm just trying to solve a problem that is still open, since
no satisfying solution has been developed still (yes I know about fst,
dssi-vst-bridge, etc. but I don't think they can be considered much
more than a well done proof-of-concept).

On the other hand I'm willing to work on different levels and with an
open mind, so that such wrapper could not only provide a robust
implementation for header-defined standards like LADSPA, and solve
some metaphorical issues which would arise with API bridges (I think
that the only API which could wrap VST decently, for example, is LV2,
but it will take a bunch of extensions), and also to introduce new
standard-independent features (eg. LASH support) as well as providing
a tool to test new solutions more easily (again, LV2 could possibly do
this, but you need a very extensions-aware program to do, for example,
per-network optimizations).

I understand that most of you don't feel the need to have such thing,
because LADSPA support is everywhere and lots of LADSPA plugins are
good, but from my point of view there are thousands of VST plugins
around and thousands of hardware machines that use VST and that little
program I'm going to write simply can't ignore this situation.
I'm absolutely pro-LADSPA/LV2, and I particularly dislike VST license,
but it's not a reason to exclude support right now. And it is not a
reason to stop experimenting new possible solutions.
At the end freedom is choice, isn't it?

Stefano



More information about the Linux-audio-dev mailing list