2009/6/19 Krzysztof Foltman <w...@foltman.com> > 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.
Ok. > > 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. > Ok #2. Stefano
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
