Re: [LAD] [RFC] LADSPA 1.2

From: Krzysztof Foltman <wdev@email-addr-hidden>
Date: Fri Jun 19 2009 - 17:15:51 EEST

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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 20:15:03 2009

This archive was generated by hypermail 2.1.8 : Fri Jun 19 2009 - 20:15:03 EEST