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

[Marek Peteraj]

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