Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: David Benson (daveb_AT_idealab.com)
Date: Wed May 24 2000 - 19:48:17 EEST
> The issue is *who* constructs the visual representation that allows a
> user to control those parameters (ports) ? The plugin ? The host ?
>
> >The plugin may very well run in an environment *without* X windows
> >(either an embedded audio application, or an audio processing server,
> >for example); or it may run in an environment where the user inteface
> >is *not* X Windows (framebuffer based toolkits, Berlin, whatever).
>
> LADSPA stands for *LINUX* Audio Development Simple Plugin
> Architecture. There are other good plugin API's for BeOS (VST, for
> example). LADSPA has never been an attempt to define a cross-platform
> API, even though it would work as one right now.
>
> Nothing that I've proposed would make it unusable on a non-X platform,
> and I specifically pointed out that a plugin should not expect that
> its "gui_constructor()" function will be called. A host is free to
> ignore the plugins wishes in this area, and build its own GUI.
1. placing the gui code in the same plugin library will force
you to link against that library, and it will
be loaded (hence must be available to the host)
when the plugin is...
2. explicitly referring to the Display* and Window
hasn't left it possible to run in non-X GUI environments
(nanogui, win32, sdl, etc... )
> My goal is precisely *NOT* to force in the UI. I want to provide a
> hook where the host can say: "OK plugin, here's your chance to create
> a GUI. Do it now, or forever hold your breath". That's all.
ok, that i agree with :)
> Suppose that a plugin wants to show the sample rate value associated
> with a particular (input) port. Suppose that another plugin is
> connected to that port, and changes its value. When and how does a GUI
> pick up the change ? GUI's are event driven - there is no event
> associated with this in LADSPA. Having GUI's poll their plugins is
> expensive, and stupid. So there is a problem here as well.
>
> gtk_timeout_add (200, poll_plugin, this_plugin) - GACK!
Well, I view this as a weakness in having the plugin
make its gui....
The host can provide this functionality itself, without polling,
by manually checking the control-port before and after
it calls run or run_adding. It is then a trivial
matter to set things up and emit the appropriate hook.
For a concrete example, here is a progress bar from
gdam that's hooked up to a volume meter (not ladspa style though):
<widget>
<class>GtkProgressBar</class>
<name>progressbar1</name>
<signal>
<name>whatever</name>
<handler>gdam_skin_adjustment:volume:progress_bar_bottom_to_top</handler>
</signal>
The ``gdam_skin_adjustment'' is a marshaller of sorts.
Basically, it *does* seem like we could build a real
standard by defining a fixed set of these guys,
and an api for new widget types to define these tags.
> ps. and yes, i have nothing better to do today than sit and write to LAD:)
ah, you reminded my i'm late for work! help i'm addicted...
- dave
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 23:43:33 EEST