[LAD] [RFC] LADSPA 1.2

[Stefano D'Angelo]

2009/6/19 Krzysztof Foltman <wdev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20090619/1dcc47cc/attachment.html>