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
