Stefano D'Angelo wrote: > 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).
I'm already thinking of reusing the same thing for DSSI, and DSSI indexes may be overlap with LADSPA indexes while referring to different plugins - while the same isn't the problem when using descriptors (they're either different or point to the same plugin). Example: dssi_descriptor may return "Synth A" as index 0 and "Effect A" as index 1, while ladspa_descriptor will only return "Effect A" as index 0. So, the index 0 may refer to the synth or the effect depending on context (LADSPA or DSSI). On the other hand, even if DSSI and LADSPA reuse the same LADSPA_Descriptor (like it was the case in older versions of Calf), both uses of this descriptor refer to the same plugin. > 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). I'm against doing it in this iteration - because state-dependent conversion is actually a more complex problem, which may be solved some time in the next 40 years. It makes sense, but benefit/risk ratio is worse than for other things already being proposed (circular flag, enums, or even my silly text-float conversion). Why is it more complex? It's because it makes it necessary to have things like inter-parameter dependencies (to be able to specify that, for example, port "filter type" affects the enum labels of "filter rolloff", or that change in a port called "delay unit" from seconds to samples should trigger a redraw of labels of ports called "delay length (L)" and "delay length (R)"). It's a whole new can of worms, one that I don't *need* opened now. And if we do it without worrying about dependencies, we end up with UI glitches (labels out of sync with current state), or inefficiency like requerying all the enum-capable ports for all the enum values after any port value change, just in case any of them changed due to state change. Krzysztof _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
