Subject: Re: [linux-audio-dev] Problem with XML for LADSPA GUI?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri May 26 2000 - 03:05:19 EEST
IMHO,
both plugs are candidates for the custom GUI,
I think implementing this feature in the GUI XML language is just
a waste since there will be too less plugins using EXACTLY that
feature in order to justify the amount of work put into the GUI language.
What if the perspective plot in a third plugin has some special requirements ?
The potential perspective widget would simply be inadequate, thus
requiring a custom GUI, or to extend the language again.
At this point I prefer the custom GUIs using the
GUI-toolkit-helpers ( which help to keep to number of running
processes low and allow smooth DSP<-->GUI communication)
And yes, about your proposed LADSPA GUI communication features
(get control value etc), I was thinking exactly along these lines.
This lib would use shared mem for local connections and TCP for
remote connecions.
That means full networking support, and full speed (no overhead
compared to monolithic DSP+GUI plugin) in case of DSP part
and GUI part running on the same machine.
thoughts ?
Benno.
On Thu, 25 May 2000, Richard W.E. Furse wrote:
> Hi there - glad to see such interest in LADSPA GUIs. I think there's a
> certain amount of arguing about nothing going on - all good food for
> thought however!
>
> I have a question about XML which a lot of people seem to be pushing as a
> framework for LADSPA GUI design. I don't know enough about XML - I hope
> this hasn't been discussed already (there's been too much to read in detail
> while moving job and flat...).
>
> Adding a GUI to a plugin has a cosmetic purpose, but can also perform a
> useful function. An obvious example is [1] a graphical filter designer
> (such as is built into the main GUI of Snd). This requires some reasonably
> sophisticated underlying logic to allow the user to move the 'fixed' filter
> response points and plot the frequency response curve that will actually be
> implemented by the particular algorithm in use.
>
> A simple example is [2] an Ambisonic encoder plugin (as present in the CMT
> at present) - this spatialises sounds in 3D. A good interface to this will
> include a perspective plot of the sound location using a mini 3D engine. We
> can see any number of other examples in this vein - a project of mine that
> I've been putting off for a while [3] allows a user to drag poles and zeros
> around on an Argand diagram and see and hear the filter response.
>
> Can we / How do we express GUIs for these three plugins in XML?
>
> -- Richard
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 07:38:12 EEST