If you meant a wrapper to handle the plugin formats on Linux in general and transparent way, its a tough goal too. One tricky part is different UI handling. I remember being annoyed by Apple and their constant change of the UI handling of their AudioUnits so I gave up on the end. I expect they change everything for OSX 10.5 again. It was a lot of trouble in one (socalled) standard/format so I guess it quadruples by throwing in several ones.
I think that's their fault, since other formats (LADSPA, DSSI, VST) tend to change very slowly over time. However UI handling would be done only after the actual processing part.
Why don't you just choose one of them (e.g. LV2) and write a 'bridge' plugin to convert the others into that one format?
Well, this in fact something that could easily be done (and has also been done), but I don't think that all of these standard have "logical compatiblity" as I say... that means the metaphor they present is not always compatible, also if their functionality is the same. Then a format wrapper would also mean that you would use all of your plugin with all applications, that you can create a standard and all your applications can use it and that a format version update would be much less painful.
Well, that's our intent in CLAM[1]. The goal is that CLAM should be able to run a given processing algorithm transparently under several backends. Currently we support, to some extend, PortAudio, Jack, Alsa, and VST. The first three backends can be used with a Qt Designer interface. We still have to face several fronts: Unifying the interface to fit all the backends, incorporating more backends (some work on Ladspa has been done), and enabling Qt GUI's to more backends (notably VST).
Well, I think I've not understood what you mean: Jack, Alsa and PortAudio are not sound processing plugin formats... can you explain it easier please? (I'm sorry, I'm not a native English speaker)
