[linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?

Lately, while looking at screenshots of a few VST(i) plugins, i began to wonder what makes them different from LADSPA plugins. Not technically, but from the philosophical point of view. VST plugins tend to be rather complex, offering tons of features and eyecandish GUIs, while LADSPAs usually offer limited functionality, no GUI at all(hosts usually provide simple ones to control the parameters). But what's interesting is that each LADSPA plugin usually implements exactly one type of DSP technique, for example, an oscillator, or a delay. This basically leads to a situation where a certain DSP technique is 'isolated' in a separate plugin. Now if we look at an arbitrary VST plugin we'll see that it's fairly complex, and that there's a large amount of creativity involved both visually and featurewise. But if you look at it closer, you'll recognize that each such plugin is actually a bunch of DSP techniques put together in a creative way. Let's look at JAMin. What makes JAMin interesting is that it's basically(although probably not entirely, haven't looked at the code) a collection of LADSPA plugins where each of those plugins implements a DSP technique dedicated to improve the characteristics of a sound in a certain way. So JAMin tends to "package" these DSP techniques into a standalone JACK effect client. Now imagine you'd replace the gtk+ based GUI with a 3d eyecandish GUI. What would you get? A typical audiomastering VST plugin. Except - it's a JACK client. So LADSPA becomes LA-DSP-A and each such plugin becomes a basic building block for a complex JACK effect or synth. The benefits i see: 1. It unifies the way audio is routed from/to/through daws, effects, synths and other audio applications. The VST(i) vs. Rewire situation becomes one - JACK. 2. If offers unlimited flexibility (together with MIDI over JACK) - for example controlling a synth with a DAW via a midi track while letting the DAW record the output of the synth. 3. It simplifies the notion of handling effects, synths etc in hosts for the users. No need for insert vs. send. 4. No need for a GUI standard. Simply write your own Gtk+/Qt frontend whether widget or pixmap based. 5. Allows developers to design complex 'plugins' i.e. JACK effect/synth clients and be creative in picking DSP algorithms and wiring them together *even* if they don't have any background in DSP programming. 6. Allows DSP developers to fully concentrate on the DSP part, only developing the desired DSP technique without caring about the rest. 7. Points 5. and 6. help to accelerate development of complex and high quality effects and synths that we all miss and the win32 and macosx users already have. 8. It would unify the LinuxAudio scene in terms of DSP code - DSP = LADSPA. Political issues: 1. we'd need to centralize the LADSPA scene on the web, using the www.ladspa.org site, building a unified ladspa directory, each entry would describe the plugin(category, author, decription, purpose) 2. the centralised site should make some general suggestions on how to build complex JACK clients out of LADSPAs, for example splitting the JACK client in two parts (GUI/engine) communicating via a standard msg bus system, such as D-BUS, which in turn would make it easier to write different GUIs for the same JACK client, Gtk+/Qt, pixmap/widget based etc. Moreover, it would help to set and improve a standard msg bus such as D-BUS. D-BUS seems to be very attractive since it's binary and comes from the desktop world which would make this issue interdisciplinary(linux desktop / linux audio) - a thing which i believe is crucial for linux in order to become a successful platform. 3. LADSPA should allow to build both complex effects and synths(technical issues? time-stamped events?) Comments? Marek