Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe maalis 10 2000 - 10:03:09 EST
I agree with everything Richard wrote, but wanted to amplify one point:
>Issue (2) above is not resolved as of Alexander Konig's post. As he pointed
>out, the host currently has no way to determine suitable ranges for sliders
>etc when generating a PVR automatically. This could be got around by just
>giving the user a textbox and hoping they'll get on with it, but I don't
>think that's terribly nice. One option is to include an optional 'suggested
>range' for each port and perhaps a 'toggle' port property. (Much as posted,
>although I prefer the idea of toggles being off if <=0 and on if >0 - this
>allows clever things to be done by connecting control LFOs to toggle
>control switches etc.) Note that this is only a *suggested* range. The
>plugin is expected to accept ANY value as in fact the user may have plugged
>in a control signal rather than entering a value (depending on host
>behaviour) and will be rather annoyed if the entire application then
>explodes. I've mixed feelings about all this - what do other people think?
When I started Quasimodo (from Csound), I decided that the range of a
control element in the GUI (knob, slider, switch, etc.) was a function
of the control element, not the parameter it "connected" to. That was
because in all properly written Csound opcodes, control values are
just floats, have no range to speak of, and certainly no way to
determine what they are. There are some less-well-written opcodes
which will blow up with the wrong values, and some, like Hans
Mikelson's otherwise fantastic moog filter opcode which even require
audio data to be scaled to 0 - 1.0. Not a very nice restriction. (*)
Since I took that route, it has mostly worked just fine, but there are
some kludges visible on the horizon. In particular: automation. If
there are ways other than the GUI to set the values of various
parameters in a plugin, and the changes are sent to the GUI for
display, then what does the GUI do if the new values are outside of the
range it uses ?
That said, I do get a good feeling about the notion that the
underlying parameters can take on any value, and that its the job of
the GUI to define control elements that limit them to some "useful" or
"cooperative" set of values. This is particularly important with
"plugins" of the kind used by aRts and Quasimodo, because the
(higher-level) "plugins" themselves consist of a series of low-level
objects which, though they may accept any range of data, may not have
the desired behaviour from an audio perspective if certain of their
parameters are not clamped so that they all work together.
Keep in mind that the plugin still specifies these values, as in the
XML spec that I posted yesterday. Its just that they belong only to
the GUI description, not to the script/source of the plugin.
Notice also that I found it very valuable to define two step sizes for
all my parameters. This allows a single GUI control element to offer
both fine and coarse adjustment; i typically use keyboard modifiers to
select which step size is in use, as well as scaling the adjustment by
other things too (e.g. pointer horizontal distance from the control element).
--p
(*) Now that I remember, this reminds me. I think it *is* necessary
for something (either the API, the host, or the plugin, or ...) to
specify the range of the audio data in use. Its hard to build generic
not-pure-DSP opcodes when you don't know if the audio data has a
dynamic range of 16 bits, 24 bits, 32 bits or whatever. If we want, we
can fix it in the API to N bits, and assume dithering by the host
(potentially via a plugin) before it is rendered to any non-N-bit
medium. But the bit size should be specified. I am not sure if 24 or
32 is the right answer: with 32 bit floats, not all 32 bit integer
values cannot be accurately represented.
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST