Subject: Re: [linux-audio-dev] ladspa gui recap
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Thu Jun 01 2000 - 21:35:04 EEST
this would be a way to go around LADSPA, the plugin itself would
fork/exec the gui process, all communication would be handled by plugin,
in this case host does not know about gui, it's basically not even part
of LADSPA, it's more like an acknowledgement that such a thing is
possible (you cannot prevent that).
this is basically the way for VERY SPECIAL plugins to do whatever they
want, an exception. once there are too many exceptions the LADSPA can be
extended...
it's just like e.g. !}fmt in vi, a way to go out of the system.
IMO it's better to have LADSPA and LADSPA-GUI simple at the beginning
and later on, when we see what kinds of plugins are written, some more
complex protocol can be designed... the bottom line is that we either
need to decide on a toolkit used (or set of toolkits, which is IMO
nightmare) or have IPC one way or another. since LADSPA does not allow
IPC, we should leave the IPC stuff outside of LADSPA, at least for now.
erik
Paul Barton-Davis wrote:
>
> >> (B). native api: support whatever toolkits you like explicitly
> >> in each plugin.
> >
> > in this case let's just let the plugin fork separate gui process (we
> >cannot forbid it anyway) and based on further experience we will see if
> >we need more organized support for this method).
>
> how can "the plugin" do this, when "the plugin" doesn't know anything
> about GUI's ? Remember, all UI's are initiated by the host.
>
> --p
This archive was generated by hypermail 2b28 : Thu Jun 01 2000 - 22:31:29 EEST