[linux-audio-dev] LADSPA needs & wishes

[Steve Harris]

On 28 Jan 2007, at 05:07, Fraser wrote:
>
>> however, it and i think all the other issues you raise are all  
>> solved by
>> LV2 (LADSPA Version 2), which has come about in part from other  
>> people's
>> difficulties with the same range of problems as you.
>
> ahh, so there is a V2 coming, not too much info about it yet out there
> (unless you know where to look)

Which is deliberate, as it's not quite finished yet. There was quite  
a lot of discussion here though.

On the "natural" parameter values, I really rather like it that way.  
Sure, it costs a bit of CPU to do the conversion, but it means that  
different plugins of the same type are more likely to be compatible,  
and it makes wiring up things in a modular synth style easier. It  
also means that things like preset files contain the same values as  
the live display, which is helpful.

When it comes to burning a bit of extra CPU power to make the users  
life easier, I'm all for it.

>> From my quick look at the LV2 spec there's something I'd like to  
>> see (this
> is just my 2c):
>
> The plugin doesn't know when a parameter has changed, so it must  
> calculate
> it's internal values from the displayed parameter 'as often as  
> possible' -
> once per run() call (doing it in the for loop itself is just too  
> extreme).

Sure. This was an issue in LADSPA, though not a significant enough  
one that anyone wanted it changed. I would suspect you're  
overestimating the burden compared to the function call overhead and  
cache thrashing. I'd be interested to see figures indicating  
otherwise though. There will obviously be cases where it's faster to  
set values using callbacks, but I'll bet it's not universal.

It's also quite convenient for both the plugin and host not to have  
to provide/call callbacks for every parameter.

...
> This has the following advantages
> 1) run() just runs (saved a bit of cpu)

But costs you some extra function calls, and makes the CPU load  
dependent on the frequency of changes, which makes predictably  
hitting RT deadlines harder.

> 2) internal values are only calculated when the parameter they are
> associated with changes

True.

> 3) changes to parameters can be presented to the run() function  
> immediately

I don't see how it makes any difference in this area?

> 4) the plugin knows when a parameter changed and so can smooth  
> jumps in
> values itself (rather then hoping to host is doing it)

Either way the plugin is free to do parameter smoothing. Typically I  
just do a linear interpolation and/or a 1st order LP filter.

- Steve