Re: [LAD] [RFC] LADSPA 1.2

Stefano D'Angelo wrote:

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

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

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

Krzysztof

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 16:15:02 2009