Subject: Re: [linux-audio-dev] more Ladspa GUI proposals
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri May 26 2000 - 00:49:06 EEST
On Thu, 25 May 2000, David Benson wrote:
> > 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.
>
> Here is the problem I guess: if you want the plugin to
> make a gui, we must standardize a toolkit or use a separate address
> space / x-connection. If we use a separate address
> space, we must standardize the synching protocol, which
> is also difficult.
>
> The "gui-in-plugin" (which implies the plugins run as a separate
> process) also has the drawback:
> - ladspa plugins will suddenly require an additional toolkit
> (otherwise it is the *hosts* responsibility to have the toolkit
> installed) (basically this *will* lead to users not
> being able to use all ladspa plugins in all hosts
> in all gui environments)
yes this is a problem, but the jumping 3D ball needs a toolkit
like gtk or Qt, there is no way around it.
On windows perhaps this is not a problem since you can assume
that the toolkit is always installed (MFC etc).
Program your 3D ball in either gtk or Qt and you will be almost 100%
certain that it will work on almost all linux distros.
> - ladspa plugins will probably be X only (embedded dsp apps
> would be excluded). I guess we don't care about this.
> - ipc and process swapping is probably going to
> hurt the extremely low-latency stuff. (i think it may
> hurt even higher-latency stuff, who knows?)
as repeated over and over again:
in a standard plugin host, the GUI will ALWAYS run as a separate process/thread
from the DSP one.
GUI <---> LADSPA control port latencies will suck (in the case of high load)
anyway , regardless of you use 1 (host with his own GUI thread managin all) or
3 (host GUI thread + GUI-helper threads) GUI threads. Therefore this is not a
vaild point againts the GUI-helper model.
The incercommunication speed between GUI and DSP will always be the same.
(I don't think that you are so foolish to run GUI and DSP processing in the
same thread)
> - It might be hard for the host to embed the plugin-made gui
> into its own gui.
Depends what you mean with embeddable:
if you make a nice API similar to LADSPA control ports, you will be able to
control/monitor pretty much everything of the plugin's own GUI.
>
> Though tractable, I think these problems are formidable,
> in the general case.
>
> Furthermore they increase the complexity of
> writing good plugins, etc. (you have to learn a gui toolkit
> to make a complete plugin-package)
Again, the reccomendation would be to use XML or the VstGUI,
the other stuff is only for special stuff.
Benno.
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 05:45:36 EEST