I'm very happy for us to start the debate on this again - I've just been
having a bit of a discussion about this with Robert Jonsson. How's this for
an approach:
STRATEGY
(A) Ideally I think that *all* hosts should be able to generate GUIs
automagically for *all* plugins. This is really neat and allows techie DSP
people to capture and interface algorithms in a way that is natural,
expressive and efficient. The absence of a Skin standard at this time
encourages good host GUI design and good plugin port hints and makes it
easy for a program to become a "full" LADSPA host, a useful marketing
point. IMHO making life simple in this way for both host and plugin writer
is really the point of LADSPA and would be a terrible thing to compromise.
Because of this I think there's a strong argument for holding off adding
Skin support for the moment.
(B) However, this isn't the whole story. If Linux wants to become a
serious contender as an audio platform, tools have to become highly non-
techie. When tools become non-techie presentation becomes much more
important. Real musicians do buy kit because they "like the big flashing
lights on the front" and the same mindset will apply here, at the host
level and at the plugin level. At some stage LADSPA will need some way to
provide skins IMHO so that plugin writers can control the look-and-feel of
their tools. I'd rather this stayed the business of the host, but marketing
is marketing...
(C) Skins should be only be able to communicate with the plugin in a way
that is mediated entirely by the host. This allows the host to capture this
communication and use it for automation. Plugins should never rely on a
skin existing to be useful as some hosts may not even have a GUI.
In summary, I suppose my opinion is that plugin skins are cosmetic. The
cosmetics industry can be ugly - but people want it anyway.
TACTICS
Whether or not skins are a good idea now, I don't think we do too much harm
by developing the ideas. How's this for a scheme:
(1) LADSPA plugin libraries may contain an additional public function
(e.g. ladspa_skin_descriptor()) which provides a (const
LADSPA_SkinDescriptor *) for one or more of the LADSPA plugins in the
library. Similar descriptor/instance model to core LADSPA.
(2) connect_port() call to wire up the control ports of the skin (port
indexes corresponding to the LADSPA plugin). This allows plugin & skin to
be linked directly to port data - or not. The skin would never be allowed
direct access to a plugin handle. We may need some sync protocol to control
access to these ports, perhaps through a lock protocol, explicit data
passing or a data sync call. My gut says the latter (haven't really thought
about it).
(3) The host should be able to take control of individual ports so
automation can go from host to GUI as well as the other way around. It
might also be nice to ask the GUI to remove support for a particular port
if it's going to be used as a streamed control port. (Probably optionally
unsupported by the GUI.) Some interesting stuff could be done with LADSPA
output control ports too.
(4) The GUI toolkit issue is a nightmare. Consider the following 'context'
list: Qt, Gtk, Java, Motif, Standalone, LTK. The last two mean: Standalone
- skin constructs its own separate Window and does its own thing
graphically. LTK - all GUI interaction goes through some VST-style
abstracted toolkit API that we'd have to spec up.
(5) We can either agree on one of these 'contexts' as the standard for
hosts (very bad except perhaps LTK) or perhaps introduce some kind of
negotiation process by which a GTK host asks the plugin "do you support
Gtk?". If it receives a no the host might also be able to support Motif,
LTK and Standalone. Or not.
I appreciate that there are very different approaches to this possible. I'm
a little reluctant about the XML approach as skins will look different in
different hosts which somewhat defeats the look-and-feel/marketing angle
(Strategy issue B). But I'm not an XML expert so this is probably a
misconception of mine.
Perhaps I should introduce a "thoughts for the future" on the LADSPA
website and post up edited highlights of these discussions (and the
categories debate)? We could develop some of the possible alternatives in
parallel.
-- Richard
-----Original Message-----
From: Paul Barton-Davis [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, May 24, 2000 2:10 AM
To: Richard W.E. Furse
Cc: Linux Audio Developer Mailing List (E-mail)
Subject: Re: [linux-audio-dev] FW: LADPSA Freeverb - update?
In message <[EMAIL PROTECTED]>you write:
>I'll be on this shortly (unless anyone else fancies a go...).
Although I am excited by this, I am a little concerned that it will be
hard to use good plugins like this without a GUI.
Our discussions about GUI's went, uh, nowhere as I recall. The closest
I got to an idea was to implement the vstGUI library in GTK, but this
doesn't really even get close to the central design issues.
--p
