28 May
2012
28 May
'12
7:30 p.m.
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:
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
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.