19 Jun
2009
19 Jun
'09
10:49 a.m.
2009/6/19 Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
I'm talking about a label box displayed next to a knob here, not a combo
box. The combo box could still be used if the parameter had an integer
hint (and reasonable range, perhaps). In such a situation, you know the
float values in advance - those are 0..UpperLimit (-:
This way, a plugin could provide appropriate formatting (with relevant
number of decimal places) for each parameter separately. They could also
decide to format some values differently (to render 0 as a text "none"
for example, or to increase the number of decimal places for small
values without using a scientific notation).
I do totally agree, and in fact what I was suggesting looks like:
struct {
float value;
const char *name;
} ladspa_port_label;
struct ladspa_port_label ** ladspa_get_port_labels(unsigned long
descriptor_index, unsigned long port_index);
This is completely orthogonal to the enum hint, and you don't have to
ask for specific float values (I repeat, if the host is going to ask
for specific values, it should know somehow which values to ask for,
which is not good for non-integer, enum and/or non bounded ports).
Stefano
What if
that extra function was more of "get textual representation of a
particular float value" (see: Buzz MDK) instead of "get all strings"?
But you would have to know the float values in advance... Well, if we use something like what I wrote
yesterday, you could do
that already (just call it port_labels instead of port_enum_values, et
voila ;-)
Explain, please?
If you mean an exported function like:
const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
float value);
it's more or less what I was talking about.
It still needs some additional specification. One missing thing is the
"lifecycle" of the returned memory block - like "it's valid until the
next call to ladspa_format_value".
Another is if it's allowed to return NULL when no custom formatting is
provided. I'd say it should be, for simplicity of a plugin. Also, it may
make sense to allow the host to assume that if a plugin returned NULL
for a specific port once, it will always return NULL for that port, so
that it doesn't need to call ladspa_format_value for that port in future.
Yet another question is if it's only usable if the "enum" port hint is
set. I think it's not, because the "enum" hint would still distinguish
between render-as-knob-like and render-as-combo-box-like situations. The
"this port is an enum and should be displayed as list of options"
capability is almost orthogonal to "this port has a custom string
renderer" capability. At least, 3 out of 4 values of those 2 bits are
very useful, and the remaining one (enum with no custom texts) isn't
harmful in any way.