Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu May 25 2000 - 13:03:35 EEST
On Thu, 25 May 2000, you wrote:
> In message <00052501354801.00879_AT_smp>you write:
> >Maurizio made very interesting points:
> >
> >I don't think that splittinhg the dsp code and GUI code
> >in separate .so files would hurt us much.
>
> if "the GUI" is just an XML template, I don't see the benefit of this.
In this case the GUI .so file will simply not exist, it's the host responsibilty
to figure out what GUIs are available.
If there is none available, it will try to construct one based on the
control ports published by the DSP part of the plugin, just as gdam does.
> I think that we've established pretty much that the GUI cannot be
> very much more than this. Running the GUI in its own address space is
> crazy (I think) from an efficiency point of view.
No, I don't think that it would be inefficient, because
you run ALL gtk-plugin-GUIs within the gtk-host-thread(process)
and all Qt-plugin-GUIs within the Qt-host-thread(process).
That means if you run hundreds of plugins, there will be only
3 threads/processes active.
-the host-DSP thread which calls the plugin DSP callbacks.
-the gtk-thread which simply loaded all gtk-widgets of the gtk-based plugins
-the Qt thread (same behaviour as above)
What is needed for the above operation is some sort of communication between the
GUI part and the DSP part, but that can easily be implemented using some form
of IPC. A standardized API which does this , would (IMHO) render the programming
model of this communication just as simple as you were running a
monolithic plugin with his own GUI (like some of the VST plugins).
Give the plugindeveloper 100% freedom (if he want to design his room simplation
with 3D GUI etc), but as a general recommendation he should use the
"standard" tools (like XML, VstGui etc) in order to ease things.
>
> >The idea of processing on one box , while doing
> >GUI stuff on another will be come very likely and
> >we need to prepare the road for this.
>
> One such road is called X11. Even if you have real DSP chip running
> plugins compiled for it somehow, that DSP chip is going to have be
> hosted by a more general purpose box. Its reasonable to assume that if
> a GUI is involved, that box can talk X11. The display can be anywhere
> else.
Better not to make this assumption:
what if one wants to run LADSPA on some POSIXish RTOS which
does not provide X11 ?
IPC / networking would work in this case but X11 not.
Ok, it's not a average casestudy, but I think my model doesn't add
overhead neither from a programming POV, nor from a CPU/scheduling
POV. (or at least only very little which is a non-issue)
>
> But again, I think we have some compelling arguments on why the GUI
> *must* be constructed by the host (or more precisely, the host's GUI
> thread) from a template provided by the plugin. That template could
> be, as in vstGUI, some object code that gets executed to construct
> some widgets, etc. Or it could be a textual specification of the
> GUI. I happen to prefer the latter.
I fully agree, the textual description speeds up plugin developement time
plus it's much more portable, since you can implement the XML GUI
parser on top of your preffered platform/GUI toolkit.
But we really should allow a multiple-widgets sets feature,
because there are some plugins which do not fit in the XML/VstGUI scheme.
(take a 3D revereb, or some surround plugins on VST: they are all programmed
using the WIN GUI directly because VSTGui doesn't provide that kind of
functionality)
my GUI wishes:
1) XML support
2) VST Gui support
3) multiple widget support (gtk,qt) provided by the GUI-handlers
1) recommended, preffered
2) manily used to easyt port VST plugins from windows to Linux
3) plugin developer should use that approach only when developing
plugins with a very complex GUI
>
> Hosts that don't want/need/support GUI's just ignore the
> specification, and create their own UI based on the port specs of the
> plugin.
Agree, but in the RTOS case above, not splitting DSP code and GUI code
in separate .so files, would not work, since the RTOS OS does not support
X11.
Benno.
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 01:03:16 EEST