29 Jan
2007
29 Jan
'07
4:08 a.m.
On 29 Jan 2007, at 02:18, Fraser wrote:
Yes, exactly. It's slightly more expensive as you have a conditional,
but you save the function call overhead, which is something like
1000-1500 cycles IIRC.
in the example code this line:
const float gain = *(plugin_data->gain);
is outside the for loop in the run() function
so changes to the gain are not picked up till the next run() call.
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change. In practice not all hosts do
that, some just pick a suitably small block size, eg. 32 frames and
quantise the changes to that rate.
- Steve
Hi Steve,
Hi Fraser,
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.
I had a thought last night about this - if I am worried about the load
from converting parameters I can always do something like:
if(current_control_value1 != last_control_value1)
{
recalculate internal_value1
}
in the run loop 3) changes to parameters can be presented to the run()
function
immediately
I don't see how it makes any difference in this area?