Re: [linux-audio-dev] ladspa plugin GUI proposal

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: David Benson (daveb_AT_idealab.com)
Date: Wed May 24 2000 - 20:24:51 EEST


> What would make sense to me is an XML spec that does some of what
> vstGUI does, plus allows the host to do its own thing if it wants
> to. The key difference with your example is that the pixmaps used are
> specified in sets using regular expressions, rather than assuming that
> you just move a given pixmap around. This is more generic than the
> motion-based assumption, because knobs require rotation which is not
> easily accomplished.

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

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...

> 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.

>
> there are other types in Quasimodo, but they could, if we want to
> limit the set of elements in the same way that vstGUI does, be
> implemented as controllers. For example, Quasimodo has:
>
> <!ELEMENT pushbutton (state)+ >
> <!ATTLIST pushbutton
> xpos CDATA #REQUIRED
> ypos CDATA #REQUIRED
> label CDATA #IMPLIED
> label_position (top | bottom | left | right | upper_left | upper_right | lower_left | lower_right) "top"
> param CDATA #IMPLIED
> trigger CDATA #FIXED "restart"
> >

yes, we'll probably want push buttons for burst controllers
and toggles for other types.

> this one is easily handled explicitly as
>
> <controller
> pixmap_regexp="pushbutton-state-[0-9]+.xpm"
> .
> .
> .
> />
>
> 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?)

> 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;

and let the host choose the xml representation.
(and the host can cache its own representation (so as to
minimize the parsing cost))

- dave


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 24 2000 - 20:57:48 EEST