Fellow LADSPA developers, I've been investigating curious bug reports concerning the use of some of the CAPS plugins in Ardour. Most notably, the Eq plugin, a 10-band graphic eq, very often consumes an inordinate amount of CPU cycles and more likely than not even produces a silent output signal (or even worse one containing only samples of inf value). [I'm talking about Ardour/GTK 0.99.3 (built using 1.4.1 with libardour 0.908.2 and GCC version 4.1.2 20061007 (prerelease) (Debian 4.1.1-16) and CAPS up to and including 0.3.0] Even after eliminating each and every possible cause of denormal numbers in the Eq plugin, the problem persisted. It turns out that it is quite simply caused by invalid control parameter values. In order to prevent zipper noise, the Eq unit (like most of the CAPS plugins) smoothens control parameter input. This is done by sweeping internal parameters over the duration of an audio block in run() or run_adding(). In order to prevent an involuntary parameter sweep during the first call to the plugin's run() after it has been activate()d, the plugin has to evaluate the current set of control input parameters in activate(). To prevent problems with unconnected ports, in CAPS an unconnected port points to the lower bound of that port's range. Thus, if a host calls activate() before doing connect_port() on all control inputs, an involuntary parameter sweep is very likely, but at least it's not starting from garbage parameters. Now, Ardour will first call connect_port() and then activate(), just as you'd expect from a well-mannered host (and as is recommended by ladspa.h). However, when Ardour calls activate(), the control inputs point at uninitialized memory (ie. garbage data). A plugin with 10 control inputs like Eq thus stands a fair chance of running into a value of nan or inf, causing all sorts of computational mayhem including the problems described above. So what to do about this? ladspa.h says nothing about the value of control inputs at plugin activation time. What it does say is that plugins should be able to operate on invalid input data without a glitch, and I'm working on making CAPS resolve the issue gracefully. But still, if control inputs are unconnected or point to a value out of bounds, nan or inf at activation time, a plugin cannot perform correct parameter smoothing. Which would be a loss, no? So, dear LADSPA host authors, estimated Ardour developers, I'd like to ask you to make sure your implementation provides plugins with valid and useful control input data at activation time, preferably the values intended to be used at run() time. Cheers, Tim PS: It'd be nice to see a recommendation to this effect in ladspa.h, too.