On Thu, 6 Dec 2001, Paul Davis wrote: > >GUIS AS PART OF THE PLUGIN > > > >As I've said before, I'd prefer an approach where an appropriate delivery > >mechanism can be chosen depending on the toolkit. Flat files may work for > >XML, or perhaps calls into the library containing the plugin itself. For > >instance, a host written in GTK might want to look for a > >"get_LADSPA_gtk_GUI()" in the library containing the plugin. If it finds it, > >fine. If not, the host might wish to look for an XML wrapper, Snd spec or > >whatever else it supports. I think it's important that it is possible to > >separate GUI and plugin (e.g. for remote control of a dedicated FX box). > > the proposal right now is to short circuit all that stuff and allow > people to write GUIs that are completely disconnected/unconnected from > the plugin. that is, the plugin doesn't know about the GUI in any way. > > the XML spec was a good idea, but (1) it has not been implemented and > (2) doesn't offer developers (read as "steve") the chance to really > "design" a GUI the way that something like libvstgui does. rather than > implement libvstgui (which i still may do), the proposal at hand will > allow people to write GUI's using any toolkit, and to have those GUIs > be useful with any host, regardless of the hosts toolkit (or lack of > one). in essence, its a "hands off" approach enabling a diverse > approach to GUIs that will maximise individual programmers' > preferences and skills with different toolkits. note: this proposal > relies somewhat on the following (evolving) API for those GUI > processes: > > ---------------------------------------------------------------------- > typedef struct __ladspa_control_protocol_client lcp_client_t; > > lcp_client_t *lcp_open (pid_t pid); > int lcp_close (lcp_client_t *client); > int lcp_write (lcp_client_t *client, > unsigned long plugin, > unsigned long port, > LADSPA_Data value); > int lcp_read (lcp_client_t *client, > unsigned long plugin, > unsigned long port, > LADSPA_Data *value); > ---------------------------------------------------------------------- > > this provides a standardized way for the GUI's to move information > back and forth with the host, and eliminates GUI authors from having > to think about how to do this. > > the main area of potential evolution right now concerns the right form > for the argument to lcp_open(). if the GUI's are always on the same > system, which they would be if fork/execed by the host, `pid' makes > sense. but for more generality, GUI's could be started on other > systems (PDA's anyone?) and then sockaddr_in or something similar > would be appropriate.
Well, its that there are good standards around for doing such (not timing critical) connection of software components - can you say CORBA? So what you need is a (little (set of)) library(ies) that, for the LADSPA plugin running in one thread, in another thread present a CORBA client (or was it a server?) that accepts parameter/port changes for the plugin and advertises its possibilities. This CORBA client/server is obviously part of the LADSPA host, so if anyone wants to do a specialized GUI for a single LADSPA plugin, he can just have that communicate through the CORBA interface (which you may want to hide in a little wrapper library to avoid too much confusion amongst the plugin developers). Richard. -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
