Paul Davis wrote: >consider a simple case where you want to ramp a plugin parameter over >the course of a call to process. if you obey current LADSPA semantics, >the only ways to do this that i can think of are: > > 1) set the control port value to the end point, and pray that > the plugin will ramp to it, based on the last value. > > 2) decide on the step size, and call process() N times with > `step' frames, altering the control port each time.
both of which are not satisfying, as you rightly observed. overall i think it is something of a serious issue since with current LADSPA control ports sudden parameter changes usually result in audible clicks, pops or other unwanted noise, depending on the plugin. therefore i think that this aspect of LADSPA needs a change. my proposal for a remedy is rather simple: let control port value pointers not point to one LADSPA_Data but to an array of two. the first represents the start, and the second the end value for the next run*() call. the choice of interpolation method will be left to the plugin which imo is the right place since the plugin author will probably make a better choice than a host. in addition, compiled plugins keep binary compatibility, though our hosts will need code changes. tim
