Subject: Re: [linux-audio-dev] ladspa GUI round 2
From: Robert Jonsson (ddskrjo_AT_dataductus.se)
Date: Sun Apr 01 2001 - 23:30:58 EEST
Paul Davis wrote:
> >I would think this is quite possible, there are nodubt GUIs that rely on
> >a LOT of parameters that would be very hard to realize if confronted
> >with the parameters itself (that is one of the reasons of having a GUI !)
>
> i think you're getting confused. yes, a plugin may have a lot of
> parameters, but as steve just noted (though i'm paraphrasing), either
> they all matter and are thus presented as control ports, or they are
> internal to the plugin and only a few show up as control ports. in
> either case, the GUI might or might not show all the control
> ports. its up to the author.
I'll back of since I have no good answer :-) My gut feeling is though that it
COULD happen that presentation and abstraction isn't perfectly 1-1.
>
> >I think the correct way when instantiating the GUI would be to ASK it
> >(the GUI) whether it supports the given plugin (by sending it it's ID),
> >if it doesn't, ask the next GUI.
>
> this has nothing to do with the scheme currently proposed. the whole
> point here is to allow people who want to create truly custom GUI's
> for their plugins to do so. there is no such thing as "a GUI
> supporting multiple plugins" in this scheme.
I might be wrong here, but my own view of this is that all GUI's are actually
executables. The first thing you need to do when about to launch a GUI would
then be to sort out what GUI belongs to the plugin in question. I guess there
are a number of more or less good options. The one I have found to be most
generic is to actually ask the GUI. This gives the benefit that we keep the door
open if anyone wishes to pursue and make several GUIs, and also make a multi-gui
which supports more than one plugin.
Example:
1. User or Host requests to open a GUI
2. The hosts finds where GUIs are located (in a subfolder of LADSPA perhaps)
3. Host asks GUI-1 if it supports the plugin
4. Plugin answers NO.
5. Hosts asks GUI-2 if it supports the plugin
6. Plugin answers YES.
Now, if the host is satisfied it will stop here and display the GUI.
An advanced host might keepon searching and make a selection on some other
basis, perhaps asking the USER.
>
>
> >Would be nice if it was possible to make a multi-gui which can support a
> >whole bunch of plugins. Both a way to give a common interface to a lot
> >of plugins and to make it easy to write multiple GUIs to a plugin.
>
> in many ways, this is what we used to be discussing the the XML
> specification. there's no way around the fact that for many plugins,
> only working in source code at the toolkit level is adequate to get
> the GUI to work "right". that means a specialized GUI per plugin.
>
> however, in the discussion to date, i have noted that we still want
> hosts to provide a default GUI in the event that the user wants one
> and the plugin doesn't provide anything. many (most?) plugins would
> fall into this category.
>
> >Not everybody wants the GUI with 2000 knobs, some want the 3 knobs and
> >one switch solution.
>
> its up to an AUTHOR what his GUI shows. if you don't like it, you can
> either make suggestions to the author, or you can write your own GUI
> (and because we're talking about using OSC, there's no reason why you
> can't have more than one GUI controlling the same plugin at the same
> time, BTW).
I am not familiar with OSC in anyway, I just wan't to raise the question.
Browsing the homepage the first thing that hits me is UDP, network support... I
read somewhere that OSC is link/bearer transparent, thus it might not be
applicable, but are you guys shure OSC is the right thing, seems to me like it's
over qualified? In other areas of this sound-platform discussion the talk has
been based very much around computer centric solutions. Everything in two or
three processes eg...Network has been dubbed to slow for instance... Does the
scope of OSC really fit the bill?
Regards,
Robert - who really has to get to bed now, curing his cold.
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 16:00:20 EEST