Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri May 26 2000 - 21:05:52 EEST
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 : Fri May 26 2000 - 21:43:21 EEST