Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat May 27 2000 - 17:31:56 EEST
I like pretty much everything in this design !
congrats.
I think what we need is an API which allows
the communication between GUI controls and hosts
in a standardized way.
If every ladspa-GUI plugin uses this, then the host
automating plugin's gui-slider (or reading the current setting)
will work just nicely.
Regardles if we are on the local box or miles a way.
Benno.
On Fri, 26 May 2000, Paul Barton-Davis wrote:
> In message <Pine.LNX.4.10.10005261020560.15479-100000_AT_luca.pas.lab>you write:
> >> well, i continue to think that the LADSPA_Descriptor should declare
> >> the GUI status of the plugin, even if the GUI (XML, .so, or whatever)
> >> is in another file. Then you just take a look at the plugin GUI
> >> requirements. Check this out:
> >
> >Agreed. Although it would be nice if the catalog format
> >allowed hosts associate gui-plugins with dsp-plugins
> >so that people could make multiple skins (not necessary written by
> >the same person either) for the dsp effect.
>
> I was thinking along the lines of a convention that the host could use
> to find a gui. Something like:
>
> LADSPA_GUI_NATIVE_GTK_EXT "-gtk.so"
> LADSPA_GUI_NATIVE_XML_EXT ".xml"
>
> If the host decides to look for one of the plugin's GUI's, it
> uses these extensions to tack them onto some agreed-upon basename of
> the plugin object itself.
>
> But sure, the catalog could be used in this way as well, and much more
> flexibly. In xml, something like this perhaps:
>
> <plugin-gui
> gtk="freeverb-gtk.so"
> java="freeverb.jav"
> >
>
> Then a host follows this logic:
>
> 1a) Given the GUI's that the host is willing&able to support (may
> be none) look in the catalog to see which objects are
> available for the plugin. (The user can set up the catalog
> with a new entry when that great new skin for freeverb comes
> along). If there are none, goto 1b below.
>
> 2a) Of the set provided, pick one, and get the relevant "helper"
> thread to load the object.
>
> OR
>
> 1b) build a (G)UI using some host-specific mechanism
>
> OR
>
> 1c) forget about UI's completely.
>
> Are there any objections to this scheme ?
>
> --p
>
> ps. I'm out of here for the (USA) 3 day weekend. Have a good one.
This archive was generated by hypermail 2b28 : Sat May 27 2000 - 18:10:15 EEST