[linux-audio-dev] processing plugin standard wrapper

Leonard Ritter contact at leonard-ritter.com
Wed Feb 14 04:18:38 UTC 2007


On Mon, 2007-02-12 at 13:23 +0100, Stefano D'Angelo wrote:
> Hi all,
> who would be interested in writing a processing plugin standard
> wrapper (LADSPA, DSSI, LV2, VST, etc.)?

i read the follow-up posts by other contributers, and i believe that
your idea is failing, because of the paradox nature of what you want.

the following example is based on experience and regards any kind of
wrapper problem.

say you are confronted with supporting 4 different interfaces. although
they all more or less target the same goal, you believe that this is 3
interfaces too much, and you would like to have only one interface to
talk to, so you don't have to learn 4 different interfaces.

because writing your own stuff yourself (problem solving) is of course
more fun than learning the interface of someone else (understanding a
solved problem), and also because you perhaps believe that you can play
an important role in the history of interface development, you decide to
write a new interface, the one to rule them all.

so you have now 4+1 = 5 interfaces. theoretically, the issue should be
solved, since you have now one central interface to talk to the other 4.

however you disregard that in the process of writing your own interface,
you learned all other 4 interfaces (so you could translate between
them), which is exactly what you wanted to avoid. of course other people
would profit from your work, ideally.

the second issue is that your 5th interface accumulates all features of
the other 4, which means that it will be the hardest to comprehend.

and this is where we enter a vicious cycle, which hints a bit on the
past of those other 4 interfaces. say, a new person comes along, as
ambitious and imaginative as you are. looking at these 5 different
interfaces, and also seeing certain superficial issues with your
interface, that person decides that those 5 interfaces need to be
wrapped up into a 6th interface.

from my experience, the solution to reducing the amount of interfaces
one has to talk to is not to add another one, but to comprehend those
that exist, and just use the most popular one, with the best licence.

the route i took for aldrin was to support none of these (since they
didn't match the problem that i had), and, if the need for a certain
piece of dsp code arises, port that code over to my private interface.

my experience is that programming by contract is something you need in a
closed source environment. in an open source environment, you usually do
fine just moving around out the code that you want, e.g. i ported
freeverb3 back from ladspa to lunar in half an hour. this way, you
exercise full control over code executed in your process.

KISSes,
-- 
Leonard Ritter

-- Freelance Art & Logic
-- http://www.leonard-ritter.com





More information about the Linux-audio-dev mailing list