Subject: Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.
From: Paul Davis (pbd_AT_op.net)
Date: Wed Mar 28 2001 - 21:14:06 EEST
>> 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 ;)
>>
>
>The Window Manager would be very unhappy about that 8-) Really, if you run
>raw X, you don't even get frames, minimising to icons etc etc. If you have
>KDE, try starting a session in "safe mode" and you'll see what it's like (just
>a raw xterm, basket-weave background, and *nothing* else -- ctrl-alt-bspace to
>exit)
Nick - this is totally unrelated to what steve was asking. he meant
just starting a new process that connects to the *existing* X
server. Just like starting a new xterm or xclock or xemacs or whatever.
>> 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.
Right, this is not the way to do it. The GUI has to send changes to
the host, perhaps via the plugin-instance-within-the-host. I'm
imagining:
struct LADSPA_Parameter_Change {
LADSPA_Handle *handle;
unsigned long port_number;
LADSPA_Data value;
};
the GUI sends these to the host via a unix FIFO (read from the host's
own GUI event loop). the host dereferences the handle value
(originally supplied by the plugin-instance-within-the-host), and then
it finds the port and changes the value to the one given.
The big problem I have with the fork-your-own-process model is the
overhead of having 32-64 processes and windows around for a situation
with a lot of plugins. not so much processor cycles as screen
real-estate management.
--p
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:39:09 EEST