On Fri, 5 Mar 2004, Tim Goetze wrote: > >the attached patch proves that LADSPA can be extended without breaking > >binary compatibility. i've compiled plugins against a patched ladspa.h > >and run them in hosts compiled against ladspa.h version 1.1 without > >experiencing any problems.
Hi, I like this new LADSPA spec. very much, thanks to Tim Goetze for working it out! However, i have one bit of concern: /* This member indicates the delay, in 1 / (sample rate) time units, the plugin imposes upon processed signals. */ const LADSPA_Data Latency; Wouldn't this break the possibility of adequate operation of plugins that have a latency value dependent on user settings (ie. not constant)? Previously it was said that only a few plugins need this, and it's hard to implement it in a host. I agree. But there *are* plugins (i have one) that rely on the possibility of varying latency to keep the output synced, and some (serious, sophisticated) hosts could still choose to implement the varying compensation. If it is forced to have a constant value, these plugins and hosts will have to face a compromise. If it is not specified as constant (ie. it can be overridden by "latency" output, or some other way on-the-fly) then the hosts that don't implement varying compensation would work no worse than with this constant spec., but the possibility to have "advanced" hosts and plugins that use it would still remain. So, i would propose to leave this Latency specification in place (for the 95% of plugins/hosts that don't need anything more), but state that the value written to the "latency" output (if that output is provided by the plugin) overrides this value and that could be changed anytime. What do you think? (This kind of usage of "latency" output has to be implemented in hosts anyway, so it may not be needed to change anything in this LADSPA spec -- maybe state in the comment that it can be overridden, that's all.) Tom