Subject: Re: [linux-audio-dev] ladspa GUI round 2
From: Werner Schweer (ws_AT_seh.de)
Date: Thu Mar 29 2001 - 12:21:18 EEST
On Wednesday 28 March 2001 20:36, Paul Davis wrote:
> i am very excited by steve's re-presentation of the plugin
> GUI-as-separate-process idea.
>
> it took me less than 10 minutes to add some code to ardour that could
> handle the IPC via a FIFO (using the LADSPA_Parameter_Change struct I
> included in my last message).
>
> if we take this route, we could skip the (quite complicated) task of
> implementing backends for the XML spec. people can write their own GUI
> "applets" in whatever toolkit they want. then, in the initialize
> callback of the plugin, they can fork the GUI process, passing it any
> necessary info via exec(2), and presto, we're done. our LADSPA's GUI's
> can be as beautiful (or ugly) as their individual authors want them to
> be.
>
> all we need to settle on is the struct used to send port value change
> requests (and its name!) and the IPC method (which i think should
> clearly be a pipe). the requests themselves don't need timestamps or
> anything complex, just a way for the host to identify the plugin, the
> port ID and the new value.
>
> note, btw, that the host may not pay any attention to the pipe to
> which requests are sent (it may even choose not to have such a pipe at
> all). i suppose the host should pass the name of the FIFO
> (e.g. /tmp/ardour_ladspa_gui_pipe), or a null pointer, so that a
> plugin can tell if and where to send GUI requests (and thus whether or
> not to bother with a GUI at all).
>
> i still that a plugin should indicate if it has its own GUI, so that
> hosts like ardour, sweep and many others can build their own simple
> GUI for those that choose not to provide one.
>
> what do you all think ? we could have this done in a few days!
>
some considerations/wishes:
- the plugin host should be able to start the gui
- the plugin host should be able to show/hide the gui
- the plugin api should not be connected to a plugin instance
the connection is made in the plugin host (IPC from gui to plugin)
- the plugin host should be able to drive more than one
plugin instance with one plugin api
- the plugin api itself accepts parameter changes via IPC
similar to a plugin instance; this allows for gui initialization
and the gui can follow parameter changes generated from other
places (automation)
- the plugin host should be able to set the "caption" (so called
in qt toolkit) of the gui; this is useful if you want to have more
than one instance of gui/plugin
Werner
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:57:55 EEST