2009/6/19 Krzysztof Foltman <[email protected]>: > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
