[linux-audio-dev] [ANN] JACK Rack 1.0

Steve Harris S.W.Harris at ecs.soton.ac.uk
Tue Nov 12 06:34:01 UTC 2002

On Mon, Nov 11, 2002 at 07:51:58 -0500, Paul Davis wrote:
> >On Mon, 2002-11-11 at 23:59, Steve Harris wrote:
> >> Its not the app that needs skinning per se, its the plugins, there is a
> >> proposed GUI standard (LCP), but its not really implemented, there are 2
> >> GUIs, but no host to support them.
> >
> >Where is this standard?
> this message (uncharacteristically for steve) is a bit confused. there
> are several proposed "standards":

Yup, sorry, I wasn't making much sense. Characteristicly for steve, he was
confused. ;)

> 1) XML description of a plugin GUI

I actually discounted that becuase I dont think any two people ever agreed
on it, and it doesn't really give us the feature that makes it worthwhile -
genuinly custom widgets.
> 2) LADSPA Control Protocol (LCP) - a protocol for a remote process
>          to control the control ports of a LADSPA plugin

Yup, thats the one I was thinking about, as paul implied though its a
bit exteme to call it a standard.

c.f. the design issues with making jack in-process clients with X guis.
It's simpler for the LADSPA case as there are a limited set of known
control interfaces to the dsp code.

The problem with this approach is that it requires a seperate process (more
or less) for each gui.

There are some (crummy looking, undocumented) examples and screenshots of
GUI's here: http://plugin.org.uk/releases/guis/

There is a version of XMMS-LADSPA that supports LCP, but its not been
released, there are still some (easy to resolve) issues with GUI

> 3) methods of establishing a GUI for a plugin

Yup, what I should have thought of were the sugestions for implementing a
standard plugin toolkit, that conceptually lives above normal X toolkits,
so you might have ladspatk-gtk, that runs in GTK programs and provides the
same API as ladspatk-qt, which runs in QT programs etc. This toolkit could
also (maybe) share the same API as libvstgui, to make commercial people
feel at home, legal issues allowing.

The problem with this approach is that is a hell of a lot of effort
upfront (though arguable less later), and you still need some way of
comminicating the port changes back to the host.

- Steve

More information about the Linux-audio-dev mailing list