My thinking re GUIs has been the following:
(1) The GUI is the responsibility of the host. The LADSPA plugin doesn't
know if it's been hooked into a Gnome, XML, Motif, Java (etc) application
or is running on a dedicated Linux-based 'hardware' synth with a two-line
LCD screen.
(2) The plugin should provide enough information to the host so that the
host can make up a useful plugin visual representation (PVR) automatically.
However, the plugin should behave sensibly whatever signal or control data
is received. This may require the plugin to do range checking on
parameters.
(3) The host may additionally provide the ability to install 'pretty'
versions of the PVR. The plugin developer may wish to ship PVRs for
well-known hosts with the LADSPA plugin itself.
I suppose what I'm saying is I don't want to the PVR implementation or API
to go anywhere near the LADSPA API itself. For instance, now that the MN
system is working I'm building a pretty GUI for it - this uses Java PVRs
and you lot would not want to use the API I've ended up with for that ;)
A sidenote on plugins that are fundamentally GUI components (e.g. real time
spectral analysers, real time mouse listeners etc): I've no objection to
these, and no objection to them kicking off other processes that connect to
X-Window, other processes or whatever. I just like the idea that, *where
possible*, plugin and GUI should be separate.
It MIGHT well be worth setting up a GUI API for LADSPA plugins for X-Window
if there is a consensus on how this should be done. Because of the variety
of graphical toolkit out there I suspect we might be better off leaving
this for the moment, but if people can agree on a common standard that
would be very cool. Even so, I'd like to avoid clouding the issue too much
with LADSPA and for the GUI API to be separate.
Issue (2) above is not resolved as of Alexander Konig's post. As he pointed
out, the host currently has no way to determine suitable ranges for sliders
etc when generating a PVR automatically. This could be got around by just
giving the user a textbox and hoping they'll get on with it, but I don't
think that's terribly nice. One option is to include an optional 'suggested
range' for each port and perhaps a 'toggle' port property. (Much as posted,
although I prefer the idea of toggles being off if <=0 and on if >0 - this
allows clever things to be done by connecting control LFOs to toggle
control switches etc.) Note that this is only a *suggested* range. The
plugin is expected to accept ANY value as in fact the user may have plugged
in a control signal rather than entering a value (depending on host
behaviour) and will be rather annoyed if the entire application then
explodes. I've mixed feelings about all this - what do other people think?
-- Richard
