Flac isn’t listed as a filetype in the open dialog pulldown. Dragging Flac files over the window sometimes opens them, sometimes throws an error. When it opens them, playback is just garbage.

-Carl

2) LADSPA has no support for plugin-defined GUI/editors.

3) LADSPA has already been superseded by the new LV2 (”LADSPA version 2″) specification which attempts to fix a number of the problems we have encountered since LADSPA was first designed. It offers ways to include a GUI/editor for the plugin (but the GUI is not part of the same process as the host). LV2 support in Linux and ported OS X hosts is still weak, mostly because we’re all too busy.

4) GMPI was intended to be the cross-industry, open plugin API but it foundered on the shoals of committee development and lack of clarity about the overall process. The GMPI spec still exists and I hope that at some point, we will see something like it emerge as a real, non-proprietary plugin API that has wide support.

“LADSPA has been released under LGPL (GNU Lesser General Public License). This is not intended to be the final license for LADSPA. In the long term it is hoped that LADSPA will have a public license that is even less restrictive, so that commercial applications can use it (in a protected way) without having to use a derived LGPL library. It may be that LGPL is already free enough for this, but we aren’t sure. Does anyone want to pay for a lawyer? In the meantime, please mail me if this is an issue for you.”

So I think what the commercial apps would have to do in the meantime is use a library under the LGPL, in other words. This format is relatively new; I can just see it becoming popular in the longer term. And it seems a wrapper would work. The advantage of the wrapper is, unquestionably, that you solve the problem once rather than independently for each app (which often involves creating a wrapper anyway). So I think we’re in agreement, given the practicalities of the situation.

Someone else may be able to give a more detailed and informed answer, though, I’m sure.

Now, there’s alot of freeware VST/VSTis for the PC right now… but I would say about 70% of it is based off of Synthedit alone… and about 75-80% if we consider all of the other plug-in development environments… all of which are commercial ventures. Which leaves about 20% which are hand-coded honest to god freeware plugs. We must also consider that alot of these remaining plugs were at one time or another commercial plug-ins that for one reason or another didn’t sell enough for the company to survive (Impulse, JXSynth, Ninja, etc.). And let’s face it, the likelyhood of an ex-developer giving away ALL of the source code to an old project, even a now freeware one is slim. Especially when we consider alot of the technology behind music software/plug-ins is based off shared technology through licensing agreements between totally separate developers.

I would say less than 10% of the freeware Windows VST plug-ins in existence are free and open enough to have their source released under the GPL. All the others for legal or technical reasons simply could not make the jump.

Now, for most host developers, the prospect of spending a significant amount of R&D, and let’s face it, legal time/money on a format that has only a fragment of the support that VST has isn’t going to really get them all fired up.

Now, that’s not to say that there won’t be some developers (Jorgen Aase, Plogue, and Sensomusic for example) that will add LADSPA support. I’m just saying, don’t expect it in the next version of Cubase, or Sonar.

FreeFrame’s situation is a little different as there were only a few, not widely supported visual plug-in formats when it first started. In order for LADSPA to be widely supported, it would have to at least dethrone DX as a secondary PC standard, and VST as a secondary Mac standard.

I don’t think that an open source plug-in format could do that for non-linux DAWs. At least, not anytime soon.

ATA