On Mon, 2012-05-28 at 17:01 +0000, Fons Adriaensen wrote:
> On Mon, May 28, 2012 at 06:05:20PM +0300, Stefano D'Angelo wrote:
>
> > IMO it's easily said: if control rate < audio rate it's plugin's
> > responsibility, otherwise the host feeds upsampled/filtered control
> > signals at audio rate to the plugin and all problems evaporate...
>
> The don't evaporate, they explode.
>
> Take a filter plugin. Calculating the actual filter coefficients
> from the 'user' parameters (frequency, gain, etc..) can easily be
> 10..1000 times more complex than actually using those coefficients
> to process one sample. So you really don't want to do that at the
> audio sample rate. A normal EQ as used in a DAW could do this once
> every 10 ms or so and use simple linear interpolation in between.
> And even that doesn't mean the filter should accept arbitrary
> 'user' parameters on each such update - these have to be rate
> limited first as well.
This is also an argument for not using signals for controls at all.
It's better in many cases to be explicitly told when the control value
changes.
That said, the comparison used to fake it isn't that expensive, but it's
more expensive than nothing (and for other port types, it is
significantly expensive)
All signs lately have been pointing to control signals sucking (except
when you actually want audio rate CV). Events are better. The details
of how to actually do that right are still unknown.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue May 29 00:15:02 2012
This archive was generated by hypermail 2.1.8 : Tue May 29 2012 - 00:15:02 EEST