2009/6/19 Krzysztof Foltman <span dir="ltr"><<a href="mailto:wdev@foltman.com">wdev@foltman.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Stefano D'Angelo wrote:<br>
<br>
> A little note, though: wouldn't it be better to pass this functions<br>
> the descriptor index rather than the descriptor pointer? (This really<br>
> is subjective taste, I guess).<br>
<br>
</div>I'm already thinking of reusing the same thing for DSSI, and DSSI<br>
indexes may be overlap with LADSPA indexes while referring to different<br>
plugins - while the same isn't the problem when using descriptors<br>
(they're either different or point to the same plugin).<br>
<br>
Example: dssi_descriptor may return "Synth A" as index 0 and "Effect A"<br>
as index 1, while ladspa_descriptor will only return "Effect A" as index<br>
0. So, the index 0 may refer to the synth or the effect depending on<br>
context (LADSPA or DSSI). On the other hand, even if DSSI and LADSPA<br>
reuse the same LADSPA_Descriptor (like it was the case in older versions<br>
of Calf), both uses of this descriptor refer to the same plugin.</blockquote><div><br>Ok.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> to ladspa_parse_value() and ladspa_format_value(), just<br><div class="im">
> in case the plugin might want to do the operations differently on a<br>
> current state basis (I don't know if this actually makes sense, but<br>
> I'm tossing this out just to know what you think about it).<br>
<br>
</div>I'm against doing it in this iteration - because state-dependent<br>
conversion is actually a more complex problem, which may be solved some<br>
time in the next 40 years. It makes sense, but benefit/risk ratio is<br>
worse than for other things already being proposed (circular flag,<br>
enums, or even my silly text-float conversion).<br>
<br>
Why is it more complex? It's because it makes it necessary to have<br>
things like inter-parameter dependencies (to be able to specify that,<br>
for example, port "filter type" affects the enum labels of "filter<br>
rolloff", or that change in a port called "delay unit" from seconds to<br>
samples should trigger a redraw of labels of ports called "delay length<br>
(L)" and "delay length (R)"). It's a whole new can of worms, one that I<br>
don't *need* opened now. And if we do it without worrying about<br>
dependencies, we end up with UI glitches (labels out of sync with<br>
current state), or inefficiency like requerying all the enum-capable<br>
ports for all the enum values after any port value change, just in case<br>
any of them changed due to state change.<br>
<font color="#888888"></font></blockquote><div><br>Ok #2.<br><br>Stefano<br></div></div><br>