Subject: Re[2]: [linux-audio-dev] ladspa GUI round 2
From: Rick Burnett (destinytech_AT_spacey.net)
Date: Sat Mar 31 2001 - 05:11:04 EEST
FWIW I thought that I would bring up one of my ideas again. I like
the idea of having 'multiple' GUI configurations, say for example
'General' or 'Advanced'. This gives the user the ability to use a
simple version that say just selects between presets ( Like my
hardware effects of the CFX12 Mixer ) or in the advanced case, goes
down to many individual settings (Like Patches on my 2101DSP).
For something like this you would need to make control ports groupable
with multiple groups and have control of which are visable. This
requires a bit of dynamic control over the GUI, instead of having a
static setup defined at initialization.
Now, as far as multiple GUI Toolkits for plug-ins, this really is a
question of how much you want a plug-in to define its own interface.
My understanding is that the XML explains how to set-up the GUI and
its up the app designer thats calling the plugins to implement the
interface. On one hand I see that allowing multiple GUI Toolkits
makes a wider array of possibilities and allows programmers to use
their skills where they know them best, but on the other hand, I feel
that one of the problems with Linux is a general lack of standards.
There are a TON of toolkits, and every author likes to use different
ones. I would not want to install an entire toolkit just to use one
plugin! By limiting to a single toolkit in the overall tool, we at
least standardize the interface across as much of it as possible.
Rick
Friday, March 30, 2001, you wrote:
>>
>>
>>> No! Or rather, not necessarily. This depends entirely on the approach
>>> of the plugin designer. If the plugin has a control port corresponding
>>> to "room size" (e.g. Freeverb), then your claim above is false. If the
>>> author, on the other hand, uses, lets say, 3 control ports whose
>>> aggregate effect is to control "room size", but then has a GUI which
>>> has a single control for "room size", then yes, you're right. But I
>>> think that this kind of design would be considered poor. The controls
>>> in the GUI should map more or less exactly to the actual control ports
>>> of the plugin.
>>
>>
>> That depends on your view as to where "UI-specific" code belongs. That is,
>> the algorithm implemented by the plug-in may make use of a parameterisation
>> that is "counter intuitive" to users - but efficient for run-time.
>>
>> You might want the GUI to translate between this and something that users
>> can deal with.
>>
>> Iain.
RJ> I would think this is quite possible, there are nodubt GUIs that rely on
RJ> a LOT of parameters that would be very hard to realize if confronted
RJ> with the parameters itself (that is one of the reasons of having a GUI !)
RJ> In this case a possible solution would be to make two version of the
RJ> plugin, one with sensible controlports and one with a sensible GUI
RJ> attached...
RJ> Brings me to another point.
RJ> I think the correct way when instantiating the GUI would be to ASK it
RJ> (the GUI) whether it supports the given plugin (by sending it it's ID),
RJ> if it doesn't, ask the next GUI.
RJ> Would be nice if it was possible to make a multi-gui which can support a
RJ> whole bunch of plugins. Both a way to give a common interface to a lot
RJ> of plugins and to make it easy to write multiple GUIs to a plugin.
RJ> If you turn it around, the host should than be able to select a "best"
RJ> GUI if there are several possible GUIs available.
RJ> Not everybody wants the GUI with 2000 knobs, some want the 3 knobs and
RJ> one switch solution.
RJ> Bottom line, leave all doors open if the need arises in the future...
RJ> /Robert
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:57:51 EEST