Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.
From: Werner Schweer (ws_AT_seh.de)
Date: Wed Mar 28 2001 - 18:33:59 EEST


On Wednesday 28 March 2001 16:13, Steve Harris wrote:
> On Wed, Mar 28, 2001 at 08:43:14AM -0500, Paul Davis wrote:
> > Since LADSPA has nothing to say about the qualities of the many varied
> > toolkits available for the X Window System, its inappropriate to
> > connect LADSPA to a particular toolkit. Ergo, its not possible for a
> > plugin to use a particular toolkit and expect it to work.
> >
> > We did discuss the idea of providing alternate GUI's. Then, if the
> > host was running, say, GTK+, it could check to see if the plugin had a
> > GTK+ GUI and use it. Or it could use the XML spec, or it could refuse
> > to implement a GUI for the plugin at all. I quite like this idea,
> > myself.
>
> I have several concerns about this, largly cos I don't know much about how
> X works at the low level. Can the plugin find out what toollkit the host is
> using? And, assuming that the host is using, say GTK+, what happens when
> the plugin tries to open a GTK window? Will it just inherit the hosts
> connection to the server?

the plugin host knows, what gui toolkit is used. If the plugin offers
a gtk+ gui, the host can use it (if he itself uses gtk+).

>
> Is there anything to prevent the plugin from spawning a second process
> which has its own connection to the server, but is linked to the process
> via some sort of IPC? I'm guessing this would be frowned on though ;)

IF the application uses more than one thread (which is typically true),
one thread is dedicated to the gui. Only one thread can process the
X11 event loop.

>
> Lastly, LADSPA plugins creating thier own GUIs kind of puts a stop to host
> automation (I think), if the plugin receives the UI events directly then
> the host knows nothing about it, and I can't think of a transparent way of
> the plugin communicating the parameter changes to the host.

Plugin and (Plugin-) gui should be handled completly separate. It should
be possible for the plugin gui to exist without any plugin instance.
Parameter changes are send as messages to the plugin host. The plugin
hosts routes this parameter changes to the gui.

This gives you:
      - one plugin gui can control more than on gui instance
        (example: two mono plugin instances for a stereo master)
      - the plugin host can record parameter changes for automation
      - the plugin host can save/restore current parameter settings
        on save/restore
      - the gui is only a "add on" the plugin host can choose to ignore

In my opinion complicated plugin guis (which cannot be described by xml)
should be implemented as separate processes which are connected to the
plugin host with a pipe to exchange messages. The gui toolkit selection
is left to the gui developer.

Werner


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:39:55 EEST