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