Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu May 25 2000 - 02:28:37 EEST
Maurizio made very interesting points:
I don't think that splittinhg the dsp code and GUI code
in separate .so files would hurt us much.
plus using the toolkit-process approach , we could
cover at least all gtk / Qt plugins for now, since
we can assume that Qt and gtk is installed on almost every
distro.
Plus if we have XML I welcome it as just an additional way
to build a GUI.
Of course the DSP only .so file is a vaild point for
headless servers.
The idea of processing on one box , while doing
GUI stuff on another will be come very likely and
we need to prepare the road for this.
so how about to build a LADSPA-GUI SDK which would contain
all infos about protocol/libraries , toolkit issues,
toolkit-handlers (the helper processes of the host) etc.
That GUI scheme will run in perfect synergy with LADSPA but the DSP
code can run totally indepentently.
Benno.
On Wed, 24 May 2000, Paul Barton-Davis wrote:
> >> If there needs to be interaction between the host and the plugin in
> >> order to create a GUI, then some information has to be exchanged
> >> between them to get this to work, by definition.
> >
> >Not by definition, it is a design choice.. Why you assume a scenario
> >where the DSP plug-in is the master and have all the knowledge ?
>
> Because there is plenty of evidence before my eyes that one of the key
> elements of writing good DSP plugins is creating really good GUI's to
> do with them. Shrugging off this design element is a big mistake - its
> just as important on the screen as if one were building a real
> physical device with real knobs and real switches. Typically, only
> someone with an overall conception of the plugin's operation can
> design a really good GUI for it.
>
> >It is the application after all that load (or ask loading) the plug-in,
> >the same application may decide which GUI module to load, and when.
>
> When you ask a plumber with 30 years experience into your house to fix
> the pipes, do you plan to tell him what to wear and what tools to
> bring ? The plugins are the masters of their domain, and you need to
> show them some respect :)
>
> >In other word, the "plug-in" may consists of more than one linkable
> >entity, and some information may stored in different form that the DSP
> >plug-in itself.
>
> Not using LADSPA. There is nothing in the API that makes such a state
> "visible".
>
> >Also, why are we supposing there is only *one* GUI for a module ?
> >
> >Take a reverb: it would make perfectly sense, in different
> >applications, to have *no* UI, or a simplified UI to choose between a
> >few presets, or a programming GUI; note that there are applications
> >where it would make absolutely *no* sense to give the user the third
> >UI.
>
> Well, I agree that there might be more than one. But the "ultimate"
> one, the one that was dreamt up by someone who really understood the
> plugin, is still desirable to have as a possibility, even if the
> situation of the current host doesn't make that appropriate.
>
> >It depends on what this information consists of; if this information
> >*is* in some form graphical (i.e. "i want a 10cm slider") there is no
> >way i know to solve this problem with a reasonable amount of
> >developement resources.
>
> We can limit the scope, just as Steinberg did with vstGUI. This *is* a
> solved problem, at least if the limitations on the widget set are not
> too restrictive.
>
> >If the information is "I have 10 int parameters, here are the names
> >and the range", this is ok, and possibly needed in the API; a
>
> "possibly" ??? how on earth can the user do anything with the plugin
> unless the host knows what things can be connected to the plugin ?
>
> >> It should be clear that I think that (1) there *must* be host/plugin
> >> interaction w.r.t the GUI and (2) the information required is minimal
> >> and can be abstracted away from the particulars of toolkits etc.
> >
> >Personally i think that:
> >
> >(1) there *may* be host/plugin interaction depending on the application,
> > and this interaction may be different in different applications.
>
> OK, I'll agree with this.
>
> >(2) abstracting away this information is equivalent, conceptually,
> > to define a small new toolkit, and then to implement it in all the
> > available toolkit.
>
> >Point 2 have a number of interesting consequences:
> >
> >a- the user interface of the plug in would be distributed with the plugin.
> > But different applications may require different UI.
> >
> >b- It would simply be a nightmare to mantains and evolve such a toolkit,
> > because there would be tens of different implementations.
> >
> >c- The toolkit must be limited to be sure that can be implemented in all
> > the toolkits; as a consequence, it risks to be left aside sooner
> > than expected.
>
> We're solving this with variations on the XML idea, perhaps.
>
> >Sorry, what i meant here is that IMHO the discussion prove that the
> >interface cannot be built by the plug-in itself without making a set
> >of strong architectural and plug-in choice; see below.
>
> Agreed.
>
> > - who *specify* the interface: the abstract toolkit above would
> > allow the plug-in to specify the interface, and the host to
> > build it; personally i think the interface should be specified
> > by a third entity, the GUI plugin.
>
> Perhaps. But for the GUI plugin to do a god job, it has to be so
> closely associated with the audio plugin that there is no particular
> difference. Besides, if the specification is just a text string, like
> XML, whats the problem with having it in the audio plugin, especially
> if the host can ignore it ?
>
> >> >The plugin may very well run in an environment *without* X windows
> >> >(either an embedded audio application, or an audio processing server,
> >> >for example); or it may run in an environment where the user inteface
> >> >is *not* X Windows (framebuffer based toolkits, Berlin, whatever).
> >>
> >> LADSPA stands for *LINUX* Audio Development Simple Plugin
> >> Architecture.
> >
> >Sorry, i *was* talking about Linux; there is a very big and growing
> >interest in Linux as an emdedded system, some of them without an UI,
> >and some other with an UI that is a toolkit built on top of the
> >Linux framebuffer device.
>
> Sure. My mistake here. I wasn't paying attention.
>
> >but it is true that the plug-in may provide a description of its user
> >interface in toolkit independent way.
>
> Right, thats what I think we're heading towards right now.
>
> >> >plug-in are a different things, that depends on many things the
> >> >plug-in itself could not care less, like the use of GNOME or KDE.
> >>
> >> But the plugin MAY care! Go take a look at jezar's freeverb web page
> >> mentioned here yesterday. Check the (VST?) GUI. To me, it looks very
> >> cool. Nothing that exists in LADSPA today would allow it to have
> >> anything like this appearance.
> >
> >What's wrong in distributing with your plug-in a Qt and/or a Gtk
> >interface for it, under the form of a widget ?
> >
> >Or under the form of a KPart (for KDE) or a Bonobo component (for GNOME) ?
> >
> >Sure, double work; but vastly better UI, w.r.t. a custom defined and
> >so limited toolkit.
>
> Because it won't work. What happens if the host uses FLTK ? or XForms?
> Or wxWin ?
>
> >> But the point at which the GUI is constructed,
> >> the way that the GUI alters port values in the plugin,
> >> the way that the GUI reflects changes in the plugin port values
> >> (automation, port connections from other plugins): these are not
> >> independent, as far as I can see, from the basic operation of a
> >> plugin.
> >
> >The construction of the GUI is independent; i.e. it is dependent on the
> >context; the same entity that load the plugin may decide to load or
> >not load the interface; the plug-in do not necessarly need to know.
>
> agreed. but if the interface is just text, i don't see the point of
> splitting them up.
>
> >The other two points, i.e. changing values, and reacting to changes,
> >are related to the way the plug-in interact with the rest of the world,
> >and are not specific to the GUI; it may be an other module, completely
> >not graphic, for example.
>
> for sure. i know this all too well, sigh.
>
> >
> >> When and how does a GUI
> >> pick up the change ? GUI's are event driven - there is no event
> >> associated with this in LADSPA.
> >
> >Good; here we agree; a event mechanism that allow to implement
> >the Observer/Observed paradigm is essential to interface a GUI,
> >and *any* other modules; it is not a GUI specific problem, and
> >should be defined w.r.t. the parameter space of the plug in API,
> >not in reference to the GUI.
>
> Agreed.
>
> >But .... : personally, i would suggest to drop completely the abstract
> >toolkit approach; it has been tried tens and tens of time, last in the
> >Java AWT, with horrible results, and finally proved to be not
> >competitive with custom build UI; the mantainance cost is horribly
> >high, and the result would be very limited, and very time consuming.
>
> I agree. This is why I like something along the lines of vstGUI, but
> specified in XML rather than C++, so that it can be implemented by
> whatever toolkit the host uses, or without it, or whatever.
>
> --p
This archive was generated by hypermail 2b28 : Thu May 25 2000 - 08:42:04 EEST