[linux-audio-dev] custom GUIs & XML GUIs ...Was: ladspa GUI round 2

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

Subject: [linux-audio-dev] custom GUIs & XML GUIs ...Was: ladspa GUI round 2
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Mar 30 2001 - 18:32:38 EEST


Hi,

my thoughts on the ladspa GUI round 2 discussion:

Paul proposed to make each custom GUI a separate process that can run an
arbitrary toolkit.

I'm not very familiar with complex virtual studio setups, but I guess in some
cases there would be dozen of plugin GUIs active.
(what's a realistic case ? anyone ?)

I'm speaking mainly from a performance point of view:

what if all these plugin GUIs start sending(receiving) tons of events to/from
host.
The host would need to poll all these processes at the same time, perhaps
causing a non negligible overhead , especially on slow machines.

Sometime ago I proposed to use only one process per toolkit.
(eg. all Qt plugins would live within the same process which would take care
to load/unload and display the qt-GUIs associated to plugins)

That way we would have only a couple of processes active which would
handle all the IPC communication with the host through a single pipe (per
GUI process).

Plus this would have the advantage that "racks" of plugins within the same
window could be easily implemented, at least for those belonging to the same
toolkit.
(eg you can display all Gtk plugins within a single window).

Am I making sense ?

Paul, are you still working on the lib that renders XML plugin-GUIs ?

I think most plugins would be perfectly happy the XML GUIs, (standard
faders,knobs,etc) and only the special ones would need a custom GUI
written in a native toolkit.

ideally we should have:

- an XML standard to render traditional plugin-GUI elements
(faders,knobs,button etc)

- a standard how to write and hookup (through a standardized IPC method)
plugin GUIs to hosts. ( the communication between GUI and host has to be two
way of course , in order to let the host remote control the GUI elements)

In my opinion the IPC stuff should be abstracted and non-blocking (lock-free
fifos), because we must take into account the cases where a realtime host has
to deal with dozen of GUI elements that can lead to the GUI stalling for long
time due to high system load.
Traditional IPC mechanisms like unix pipes (4096bytes in size) might fail
in the above case causing either the loss of events or the blocking of the
sender which in the case of a lowlatency-audio host would lead to audio
dropouts.

Thoughts ?

cheers,
Benno.


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:57:52 EEST