Hi Steve,
>> 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. I took me a while to find this list. The http://www.ladspa.org site refers to the linux audio developers mailing list as being here: http://www.linuxaudiodev.com/ which has had nothing but a holding page since the middle of last year... > 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. Perhaps I am yes. I am more thinking about the consequences of this when running 40+ plugins as the same time (mixing in VST for example I'll use that many plugins easily). With that many the conversions would add up to something but like you say it could be neglible. I'll try to benchmark it and post some results. 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 BTW this all came about from one of the plugins I'm working one - 10 parameters from which 50 internals are calculated - lots of sin,cos,tan,pow & sqrt's going on. By keeping track of the previous values at least I can recalculate when I detect a change rather than every run() call. >> 3) changes to parameters can be presented to the run() function >> immediately > > I don't see how it makes any difference in this area? 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. whereas in my example I had my (magically converted) parameter inside the for loop - so any changes are picked up immediately: for (pos = 0; pos < sample_count; pos++) { output[pos] = input[pos] * plugin_data->MyTranslatedGain; } When you consider plugin parameters can be automated and music is all about timing, having an unpredictable delay between when a parameter is changed and when the new value is applied could be an issue (ie you can't make the sound being produced by a plugin change 'on the beat'). With my setup, blocks of audio are 2048 fames in size, so my run() function will pick up changes every 46ms - which is an audible delay (yes I agree this is a small deal and if really matters to the plugin there are ways around it) regards, Fraser
