Re: [LAD] [RFC] LADSPA 1.2

From: Krzysztof Foltman <wdev@email-addr-hidden>
Date: Fri Jun 19 2009 - 16:33:11 EEST

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.

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 20:15:02 2009

This archive was generated by hypermail 2.1.8 : Fri Jun 19 2009 - 20:15:02 EEST