Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 24 2000 - 20:17:41 EEST
> 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...
this is an excellent point that I was not paying attention to.
> 2. explicitly referring to the Display* and Window
> hasn't left it possible to run in non-X GUI environments
> (nanogui, win32, sdl, etc... )
Thats why i wrapped it in the somewhat coy:
some_type_that_can_be_losslessly_cast_to_Display *;
But anyway, that idea clearly doesn't work, as I've already outlined.
>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.
I don't think this is as simple as you imply, but anyway, yes, if the
GUI is constructed by the host, then this is definitely easier.
>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>
This is the wrong way around, I think, for LADSPA. The ports are
simple, indivisible data types (e.g. float), for efficiency's
sake. There is no way to connect anything to them and expect any kind
of notification that they've changed. This is why your point about
having the host construct and run the GUI is well-taken: it can both
drive the port values when relevant GUI events happen, and drive both
the GUI and the port values in the case of automated playback of
events.
--p
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 20:46:23 EEST