[linux-audio-dev] more Ladspa GUI proposals

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

Subject: [linux-audio-dev] more Ladspa GUI proposals
From: Robert Jonsson (ddskrjo_AT_dataductus.se)
Date: Thu May 25 2000 - 11:30:34 EEST


I have been pondering these questions from my own naive view...

I don't know alot about the exact way LADSPA works, but I'll try to explain my
thoughts.

Ladspa plugs are built as dynamically loaded libraries. These are loaded by the
host which in turn reads some data from the plugin to find out what data it
needs. The host can then choose (well right now it HAS) to generate a GUI which
makes it possible to change this data.

What I've read so far there are a few concerns with plugs and GUI's:
1 - They should be separated for performance and resource reasons
2 - Automation must be possible / Saving of state data is then also available
3 - It must be easy to implement
4 - There are concerns with different GUI toolkits, very hard to solve....
5 - There is a separation between control and audio data, which both may be of
use for the GUI.
6 - The plugin should not depend on the GUI to operate.

Myself I am mostly concerned with simplicity (besides GUI's in general). It is
a key factor to make a technology wide spread. I have understood that this is
one of the reasons LADSPA was initially released without any support for GUI's.
In retrospect I must say I think this was a wise move, for the time beeing. In
the short time I've been following LADSPA, it has grown to the closest we have
to an industry standard.

Enough with general ramblings.

Lets make an assumption:
- The only data the GUI needs is the data already published through thte LADSPA
data descriptor (or what it was called).

If this is infact true (perhaps it can be MADE true?) would it not be a valid
alternative to let the host instantiate a GUI and connect it to itself acting as
a proxy, forwarding all information to the already available connection to the
LADSPA plugin??
In other words the GUI would be a simpleminded host, thinking it is directly
connected to the plugin, (not that it ever should be connected to the plug
directly).
It seems to me that this method could be developed into a very simple
architecture that would change very little in the already available system.
From my six points above this model would solve 1,2,3 (i think :-}) and 6.

It strikes me also, IF the GUI for the plugin is a separate entity, could it not
be a program in it self, would it hurt much?? The passing of data to the host
must be solved in some elegant way.... By making it a self operating application
point 4 would arguably be solved also.

Do I at all make any sense? :) Well my intentions where good atleast....

Regards
Robert


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

This archive was generated by hypermail 2b28 : Thu May 25 2000 - 16:05:17 EEST