Subject: Re: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Fri Dec 07 2001 - 11:36:49 EET
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 <richard.guenther_AT_uni-tuebingen.de> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
This archive was generated by hypermail 2b28 : Fri Dec 07 2001 - 11:32:36 EET