Subject: Re: [linux-audio-dev] LADPSA GUI
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Wed May 24 2000 - 19:04:06 EEST
I think there should be two modes of plugin operation.
mode 1: host controlled/docked:
this way the host would have complete control over the plugin, using
plugin parameters to construct GUI for plugin, host would also
commuinicate gui changes to plugin and vice versa.
mode 2: standalone
plugin gets (or creates) its own window that it handles completely by
itself - this will be harder to design, the easiest way would be for
plugin to fork off the GUI part, but then we have IPC that slows things
down... anyway, I think that it's better to start with simple and
elegant design and optimize later.
plugins can support/require one or the other or leave it to host...
erik
Karl JH Millar wrote:
>
> I've been thinking about these GUI issues somewhat.
>
> There is a conflict between plugins being able to control how they look/feel
> and the look/feel of the host. Personally, I think that the look/feel of the
> host should take priority, and we want to work to give the plugin as much
> flexibility as possible within that. I certainly don't want to have to try to
> mix sound with 23 differently shaped buttons, dials, faders etc on my screen.
> I'd rather have just one, even if it means I have to miss out on a little
> chrome.
>
> In particular, this implies that either we standardise on a toolkit or rely
> on the host to draw the plugin.
>
> The only practical way to standardise on a toolkit in a linux system is to
> make our own API. This is necessary both as there are too many toolkits out
> there, and also as audio plugins tend to want controls not provided by any
> of the widget sets in common usage (eg dials and faders).
>
> If instead we rely on the host to draw the plugin, then we need a way to
> request how the plugin should look. This can be done at a range of levels,
> ranging from just supplying the information already in the ladspa API, to
> something more like the XML descriptions used by libglade, which would give
> the plugin almost complete control over how it is displayed.
>
> This latter method strikes me as the much better option. It is toolkit
> independant, and if well constructed allows the host to ensure that
> all the plugins have a consistent look and feel, while allowing the plugin
> plenty of leeway in layout. It makes it simple for hosts to capture user input
> and it also removes the burden of dealing with multi-threading issues away
> from the plugin and into the host, where I believe it belongs.
>
> This also makes plugin GUI construction relatively easy (in fact one could
> probably modify glade to create a graphical plugin GUI generator).
>
> The disadvantages of such a system are:
> - Plugins may not be able to manipulate the widget. This is sometimes
> useful, and is a potentially serious limitation (although we should
> be able to work around this problem in most cases).
> - Plugin designers may have less control over the look of their plugin
> (less chrome, same layout and functionality)
> - Hosts need code to turn a description into widgets, making host
> construction more complicated. This may be mitigated by creating
> libraries which do this.
> - Plugins would be restricted to whatever widget types are defined in
> the standard, and would not be able to create their own.
>
> Karl.
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:41:31 EEST