Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 24 2000 - 20:54:02 EEST
>in gdam we use two mechanisms:
>
> - pixscrollbar : as described but the "bauble" has the usable
> widget states (inactive, active, prelit, selected,
> disabled)
> - pixsplitbar : comes in horizontal and vertical (just one class
> though), which takes two pixmaps:
>
> +-----------------------+----------------+
> | 60% of image A | 40% of image B |
> +-----------------------+----------------+
> ^
> clicking on this line
> sets the scrollbar to this
> configuration
ouch! just do it the vstGUI/Quasimodo way, and have about 20-30
pixmaps for the slider, covering all positions. It works fine.
I just catch state changes and ignore them. prelight is absurd, and I
never want deactivate, disable, or select to alter the
appearance. this is an idea that is a carryover from generic widget
sets, and i don't think its relevant here. bite me!
if you really want, just use a different gc to display the pixmap for
different states (e.g. change the colormap).
>i've wanted knobs but have generally been trying to
>limit the number of pixmaps needed, so i haven't done that.
>i'll have to look at the quasimodo knobs...
I typically use 32 pixmaps for the knobs. that seems to result in a
nice smooth motion, at least for the roughly 25x25 pixel knobs that i
tend to use.
>> Experience with Quasimodo suggests to me that in addition to a
>> controller, we also need:
>>
>> soundfile selectors
>> oscilloscopes
>> curve displays/editors
>
>hmm... i'd like these but the only reason they
>can exist in gdam is becuase of typed-parameters
>which ladspa doesn't have.
yes, this is a bit of a problem. there is no way to provide a plugin
with a control curve for say, a compander, without simply specifying N
port values, and hoping that it interpolates between them in the right
way.
this will have to wait for a future version, its too fundamental to
get sidetracked with right now.
>> There would most likely just be two pixmaps matching that regexp.
>
>but, uh, how is how is the host supposed to ascribe semantics
>to that control? (or are you saying that different semantics
>are fundametanlly bad?)
the number of button states gives the number of port values. when the
host uses pixmap #2, it sets the port value to 2 (at the appropriate time).
the plugin controls this by supplying the pixmap regexp. at least
thats how it works in quasimodo.
>> Then we have:
>>
>> some_xml_type *(*get_gui_template)(LADSPA_Handle);
>>
>> as part of the plugin. If it returns NULL, the plugin doesn't have any
>> particular ideas about its own GUI, and the host should do its best.
>
>Yes, this is good, frankly i might just advocate:
>
> const char* xml_template;
to compromise (and allow Maurizio's point that the GUI spec might live
elsewhere:
const char *(*get_gui_xml_template)(LADSPA_Handle);
Note: perhaps this function ptr can also *be* NULL ...
--p
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 22:03:46 EEST