linuxaudio.org

On Mon, 2012-05-28 at 17:01 +0000, Fons Adriaensen wrote:

quoted text
> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev