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@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
