13 May
2003
13 May
'03
9:50 p.m.
Hi,
i'm new to this list but tried to catch up by reading the archives. I'm
currently playing around with a gui-backend based on Qt which uses the
proposed ladspaxmlgui.dtd.
If have some questions concerning the controller element.
<!ELEMENT controller (graphics-context?)
<!ATTLIST controller
port CDATA #REQUIRED
label CDATA #IMPLIED
label-position (top | bottom | left | right | upper-left | upper-right |
lower-left | lower-right) "top"
type (knob | hslider | vslider | spinner | image) "knob"
image-regexp CDATA #IMPLIED
First, what is the label intended to contain ?
- the port name
- user definable text
- the port value
Second, imagine a normal slider or knob in an everyday plugin. Surely it is
fine to use the slider/knob to go wild changing the value interactively. But
what if i want to specify a value precisely . Fiddling around with my mouse
until i managed to set the desired value ? What if, even worse, the gui
doesn't snap to my value according to pixel inaccuracy.
IMHO the solution to this problem is a numeric input for LADSPA_Data values,
that could be placed above/below/... the slider to display and edit the
value. In fact the input could be placed everywhere in the gui, theres no
actual connection between them apart from the numeric input being attached to
the same port as the slider is. Is this possible (dont see why it shouldn't)
?
The numeric input might be usable not only in combination with a slider, but
also as a standalone controller.
Thus i propose an additional control element of type "numinput".
One problem arising from the slider example (and not when used standalone) is
:
If used in the way described above (slider + numinput below) we have a label
for both controls. What to do with these two ? According to the documentation
in the dtd, the label "should always be supplied for user-convenience". The
solution in this case might be to add the attribute "none" to the
label-position attribute list. According to the comments in the dtd this is
one of the rare situation one of the labels is optional.
To put this altogether my controller element section would look like this:
<!ELEMENT controller (graphics-context?)
<!ATTLIST controller
port CDATA #REQUIRED
label CDATA #IMPLIED
label-position (none | top | bottom | left | right | upper-left | upper-right
| lower-left | lower-right) "top"
type (knob | hslider | vslider | spinner | image | numinput ) "knob"
image-regexp CDATA #IMPLIED
There might arise questions about display precision for float values, but i
would leave this up to the gui element itself. In my Qt implementation i
adopt the number of decimal places according to the value displayed. The
larger the absolute value the lesser decimal places ( e.g.: 1.214, -10.23,
935.3, 16003 );
Comments are welcome.
//Peter
--
"Without music, life would _O_/ \_O_/ +----------------------+
be a mistake - I would / )) [] | Peter Eschler |
only believe in a god who \\ // | peschler(a)t-online.de |
knew how to dance." (Nietzsche) // \\ +----------------------+
13 May
13 May
11:34 p.m.
i'm new to this list but tried to catch up by
reading the archives. I'm
currently playing around with a gui-backend based on Qt which uses the
proposed ladspaxmlgui.dtd.
you're the first to do anything with it. just so you know.
First, what is the label intended to contain ?
- the port name
- user definable text
- the port value
the port name.
Second, imagine a normal slider or knob in an everyday
plugin. Surely it is
fine to use the slider/knob to go wild changing the value interactively. But
what if i want to specify a value precisely . Fiddling around with my mouse
until i managed to set the desired value ? What if, even worse, the gui
doesn't snap to my value according to pixel inaccuracy.
it was imagined that this is up to the particular widget to handle in
the "right way". i would rarely (if ever) use a knob widget that
didn't include a numeric display/input field as well, for example. i
don't consider the decision on what type of widget to use to be based
on the required precision: all controllers should (must?) be capable
of arbitrary precision.
however, i would agree that a "numinput" type as an explicit choice by
the GUI designer might not be a bad addition.
just keep in mind that nothing, absolutely nothing, has happened with
the LADSPA XML GUI proposal for at least 18 months, perhaps
longer. there are no plugins with GUIs written using the DTD.
14 May
14 May
7:15 a.m.
On Tue, May 13, 2003 at 09:28:03 -0400, Paul Davis wrote:
it was imagined that this is up to the particular
widget to handle in
the "right way". i would rarely (if ever) use a knob widget that
didn't include a numeric display/input field as well, for example. i
don't consider the decision on what type of widget to use to be based
on the required precision: all controllers should (must?) be capable
of arbitrary precision.
[stating the obvious] except TOGGLEs and INTEGERs ofcourse. I've used knob
widgets in some UIs where, on minor controls the value was a sort of
editable tool tip that only appeared when the knob has focus. Works pretty
well.
just keep in mind that nothing, absolutely nothing,
has happened with
the LADSPA XML GUI proposal for at least 18 months, perhaps
longer. there are no plugins with GUIs written using the DTD.
Right. My option is that its a pretty niche thing, there are a few plugins
that would benefit from something like this, without custom widgets, but
not a huge number.
- Steve
8:36 a.m.
On a somewhat related topic: there's one thing I'm missing in the
LADSPA parameter hints. Sometimes you need a control that is
logarithmic, but that does go down to zero. Fer example, the
frequency modulation gain of a VCO needs very small values for
things as vibrato, large values for FM synthesis, and at the
same time you want to be able to swicth it off without disconnecting
the source.
If 0 <= p <= 1 is the 'slider position', and a, b are the parameter
limits given in the hints, and x the parameter value, then a linear
control does
x = a + p * (b - a)
and a logarithmic one does
x = f (p) = a * epx (p * log (b / a).
Could we add a hint bit saying that the mapping should be
x = p * f (p), with f (p) as above ?
Another useful bit would be one saying 'display in dB'. Combined with
the other one, this would give a reasonable fader.
Fons
9:36 a.m.
On Wed, May 14, 2003 at 12:23:56 +0200, Alfons Adriaensen wrote:
Another useful bit would be one saying 'display in
dB'. Combined with
the other one, this would give a reasonable fader.
Agree with your first point, LOGARITHMIC is a bit underspecified.
For dB controls I just use dB's as the units.
- Steve
10:07 a.m.
On Wed, May 14, 2003 at 12:25:33PM +0100, Steve Harris wrote:
On Wed, May 14, 2003 at 12:23:56 +0200, Alfons
Adriaensen wrote:
Problem then is that the lower limit is minus infinity...
FA
Another useful bit would be one saying
'display in dB'. Combined with
the other one, this would give a reasonable fader.
Agree with your first point, LOGARITHMIC is a bit underspecified.
For dB controls I just use dB's as the units.
11:10 a.m.
On Wed, May 14, 2003 at 01:55:39PM +0200, Alfons Adriaensen wrote:
On Wed, May 14, 2003 at 12:25:33PM +0100, Steve Harris
wrote:
True, I do what hardware devices do and declate -some_small_val to be -Inf,
and either crossfade to 0 from -some_small_val+delta to some_small_val, or
its its low enough just zero it at the minimum value.
- Steve
On Wed, May 14, 2003 at 12:23:56 +0200, Alfons
Adriaensen wrote:
Problem then is that the lower limit is minus infinity... Another useful bit would be one saying
'display in dB'. Combined with
the other one, this would give a reasonable fader.
Agree with your first point, LOGARITHMIC is a bit underspecified.
For dB controls I just use dB's as the units.
11:58 a.m.
On Wed, May 14, 2003 at 01:59:52PM +0100, Steve Harris wrote:
True, I do what hardware devices do and declate
-some_small_val to be -Inf,
and either crossfade to 0 from -some_small_val+delta to some_small_val, or
its its low enough just zero it at the minimum value.
That solves the problem internally, but the displayed value is wrong. Not that
it matters much excep maybe for a real mixer plugin.
There a trick to get this right, but it requires some understanding between the
plugin and the host. Say you want a fader with a range from -Inf to +10 dB, with
-60 dB being close to the bottom. Specifiy a range -61 to +10. Internally you
crossfade to zero gain between -60 and -61. A medium intelligent host would put a
scale along the slider with ticks every 10 dB, and the user would infer that the
lower limit is -Inf.
ladspa.h suggest you should use a slightly expanded range for integer parameters,
e.g. 0.9 to 10.1 if you want 1 to 10. Is this only to absorb errors in the
pixels -> value mapping, or has this another purpose ? Note that if the plugin
uses intparm = floor (x + 0.5), there should be no problem at all.
FA
12:59 p.m.
On Wed, May 14, 2003 at 03:46:20PM +0200, Alfons Adriaensen wrote:
But conceptually it is OK.
True, I do
what hardware devices do and declate -some_small_val to be -Inf,
and either crossfade to 0 from -some_small_val+delta to some_small_val, or
its its low enough just zero it at the minimum value.
That solves the problem internally, but the displayed value is wrong. Not that
it matters much excep maybe for a real mixer plugin. There a trick to get this right, but it requires some
understanding between the
plugin and the host. Say you want a fader with a range from -Inf to +10 dB, with
-60 dB being close to the bottom. Specifiy a range -61 to +10. Internally you
crossfade to zero gain between -60 and -61. A medium intelligent host would put a
scale along the slider with ticks every 10 dB, and the user would infer that the
lower limit is -Inf.
I dont think it matters, the user just wants minimum, so they stick it at
the bottom.
ladspa.h suggest you should use a slightly expanded
range for integer parameters,
e.g. 0.9 to 10.1 if you want 1 to 10. Is this only to absorb errors in the
pixels -> value mapping, or has this another purpose ? Note that if the plugin
uses intparm = floor (x + 0.5), there should be no problem at all.
yes, or intparm = lrintf(x). I think ladspa.h is wrong to suggest that, I
dont do it.
- Steve
8:29 a.m.
i'm new to
this list but tried to catch up by reading the archives. I'm
currently playing around with a gui-backend based on Qt which uses the
proposed ladspaxmlgui.dtd.
you're the first to do anything with it. just so you
know.
7660
days inactive
7661
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Jay Vaughan -
Paul Davis -
peschler＠t-online.de -
Steve Harris