[LAD] [RFC] LADSPA 1.2

[Stefano D'Angelo]

2009/6/19 Krzysztof Foltman <wdev at foltman.com>:
> Stefano D'Angelo wrote:
>
>> 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);
>
> We are talking about two different things here.
>
> You've described an API to return specific, named points within a range.
> Kind of tick marks on a slider, with associated labels.  So that you can
> have a slider that has "cold" at zero value, "cool" at 25% and "hot" at
> 100%. Is that right? The same API could also be used for returning
> values and descriptions for enum ports (but not continuous ports, as it
> would require about 2^32 port labels :) ).
>
> On the other hand, I'm talking about a basic custom float-to-string
> function. Something I could implement so that cutoff frequency for my
> plugin could be formatted as "%0.0f Hz", while the delay time could be
> formatted as "%0.2fms" for small values and "%0.0fms" for large values.
> Also, I could use it to format 0 as "Lowpass", 1 as "Highpass", etc., in
> an integer port that I use for filter type. Which I could, also, mark as
> "this is enum" with a sort of new hint we were talking about previously.
>
> So far, I've seen more uses for formatting continuous values (a little
> label next to a knob) than providing tick marks for continuous values.
> However, there's a relatively simple solution to have both:
>
> // this gives us text-to-string for arbitrary floats (side effect of
> which is being able to implement enums)
> const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
> float value);
> // this tells us which float values have "interesting" meaning
> void ladspa_get_scalepoints(LADSPA_Descriptor *descriptor, int port, /*
> [out] */ float **values, /* [out] */ int *values_count);
>
> It may seem *very slightly* less efficient, but that should be OK, as
> it's a microseconds-range difference in non-RT code.
>
> For "normal" enums and custom-rendered parameters you'd only need the
> first function anyway.
>
> For completeness (I'm probably starting a flamewar here) we might also
> have a reverse function, like:
>
> float ladspa_parse_value(LADSPA_Descriptor *descriptor, int port, const
> char *value, const char **error);
>
> which would allow to convert user-entered values (like delay times in
> seconds, milliseconds, centuries, Hertz etc. - or frequency ratios in
> cents, semitones, octaves...) to a float value expected by given port,
> optionally returning an error message if the text value is illegal.

Ah, now I understand. Well, I have nothing against this ;-)

A little note, though: wouldn't it be better to pass this functions
the descriptor index rather than the descriptor pointer? (This really
is subjective taste, I guess).

Other than that, maybe you could also pass the plugin instance (should
be optional) to ladspa_parse_value() and ladspa_format_value(), just
in case the plugin might want to do the operations differently on a
current state basis (I don't know if this actually makes sense, but
I'm tossing this out just to know what you think about it).

Stefano