Re: [LAD] [RFC] LADSPA 1.2

2009/6/19 Krzysztof Foltman <wdev@email-addr-hidden>:
> 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.

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
_______________________________________________
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:03 2009