Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Thanks, Lubomir.
BTW, some points I'm sure are not news to most here, but I'm including for the
casual reader:
First, we've already talked about choosing an algorithm with better numerical
properties as the best, and almost always sufficient (particularly with
double-precision), choice. For instance, the reason for using transposed direct
form II with floating point is because the summations are with values that are
closer in magnitude to each other, avoiding large FP errors. (Also, other
"non-direct" forms can bias precision where it's most needed. For instance, the
direct forms have more trouble placing poles precisely at low frequencies than
high, while other forms can have a uniform distribution or be biased for more
precision at the low end.)
Also, if you really must do something to keep track of the error—perhaps with a
processor that only handles single-precision floating point—it's only necessary
to do it on the feedback portion of the filter. So some of the cycles Ross
mentioned could be scrapped. The feed-forward (zeros) portion is not so
sensitive, since the errors don't recirculate.
On Nov 14, 2013, at 11:20 AM, Lubomir I. Ivanov wrote:
> On 14 November 2013 19:45, Nigel Redmon wrote:
>> Hi Ross,
>>
>> Well…that's part of what I mean by, "Of course, the alternative is to roll
>> your own, whether fixed or floating point"—in this case doing the
>> calculation then undoing it to see what the error was. But that's just the
>> summation. There is error in the multiplies as well, since they are always
>> truncated. Contrast that with doing noise shaping on the 56k, where there is
>> zero error until you store to the 24-bit delay elements, and it's trivial to
>> recover that error.
>>
>
> no sure if further useful, but for completeness and since i haven't
> contributed anything else in a while...
> this i haven't tested much, but it should work for any type as long as
> you get the 'factor' correctly.
>
> --
> /*
> Veltkamp / Dekker's TwoProduct algorithm
>
> T. J. Dekker, A Foating-point technique for extending the available precision,
> Numer. Math., 18 (1971), pp. 224{242.
>
> http://oai.cwi.nl/oai/asset/9159/9159A.pdf
> */
>
> #include
>
> #define FS(x) x##f /* type suffix */
> #define FT float /* floating point type */
> /*
>factor estimation is done by:
>2 ^ ceil(log2(2 / epsilon)) / 2) + 1;
>float:
>(1 << 12) + 1 = 0x1001 = 4097;
>double:
>(1 << 27) + 1 = 0x801 = 134217729;
> */
> #define factor FS(4097.0)
>
> FT two_product(const FT a, const FT b)
> {
>FT x, y, c, a1, a2, b1, b2, res;
>
>/* split x into a1, a2 */
>c = factor * a;
>a1 = c - (c - a);
>a2 = a - a1;
>
>/* split y into b1, b2 */
>c = factor * b;
>b1 = c - (c - b);
>b2 = b - b1;
>
>x = a * b;
>y = a2 * b2 - (((x - a1 * b1) - a2 * b1) - a1 * b2);
>return x + y;
> }
>
> int main(void)
> {
>/* not much testing went in here... */
>const FT a = FS(123456789.0);
>const FT b = FS(123456789.0);
>printf("%.7f, %.7f", a * b, two_product(a, b));
>
>return 1;
> }
> --
>
> lubomir
> --
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp
> links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 14 November 2013 19:45, Nigel Redmon wrote:
> Hi Ross,
>
> Well…that's part of what I mean by, "Of course, the alternative is to roll
> your own, whether fixed or floating point"—in this case doing the calculation
> then undoing it to see what the error was. But that's just the summation.
> There is error in the multiplies as well, since they are always truncated.
> Contrast that with doing noise shaping on the 56k, where there is zero error
> until you store to the 24-bit delay elements, and it's trivial to recover
> that error.
>
no sure if further useful, but for completeness and since i haven't
contributed anything else in a while...
this i haven't tested much, but it should work for any type as long as
you get the 'factor' correctly.
--
/*
Veltkamp / Dekker's TwoProduct algorithm
T. J. Dekker, A Foating-point technique for extending the available precision,
Numer. Math., 18 (1971), pp. 224{242.
http://oai.cwi.nl/oai/asset/9159/9159A.pdf
*/
#include
#define FS(x) x##f /* type suffix */
#define FT float /* floating point type */
/*
factor estimation is done by:
2 ^ ceil(log2(2 / epsilon)) / 2) + 1;
float:
(1 << 12) + 1 = 0x1001 = 4097;
double:
(1 << 27) + 1 = 0x801 = 134217729;
*/
#define factor FS(4097.0)
FT two_product(const FT a, const FT b)
{
FT x, y, c, a1, a2, b1, b2, res;
/* split x into a1, a2 */
c = factor * a;
a1 = c - (c - a);
a2 = a - a1;
/* split y into b1, b2 */
c = factor * b;
b1 = c - (c - b);
b2 = b - b1;
x = a * b;
y = a2 * b2 - (((x - a1 * b1) - a2 * b1) - a1 * b2);
return x + y;
}
int main(void)
{
/* not much testing went in here... */
const FT a = FS(123456789.0);
const FT b = FS(123456789.0);
printf("%.7f, %.7f", a * b, two_product(a, b));
return 1;
}
--
lubomir
--
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Hi Ross, Well…that's part of what I mean by, "Of course, the alternative is to roll your own, whether fixed or floating point"—in this case doing the calculation then undoing it to see what the error was. But that's just the summation. There is error in the multiplies as well, since they are always truncated. Contrast that with doing noise shaping on the 56k, where there is zero error until you store to the 24-bit delay elements, and it's trivial to recover that error. Nigel On Nov 14, 2013, at 4:56 AM, Ross Bencina wrote: > Hi Nigel, > > On 12/11/2013 8:52 PM, Nigel Redmon wrote: >> The problem is that the error is lost in the floating point >> hardware—you put in two floats and get back float of the same size. >> Something fell into a "bit bucket" that you don't have access to. > > I figured that there must be some way to recover the error. > > After some research it turns out that there is something called "error free > transformation". This paper [1] gives two methods, one from Knuth AOPC vol 2 > p.236 (which unfortunately I don't own), and one by Dekker (1971): > > a and b are the numbers we'd like to sum. > x is the result. y is the rounding error (the bits that fell into the "bit > bucket" as you said above). > > From the paper: > > function [x; y] = TwoSum_Knuth(a; b) >x = float(a + b) >z = float(x - a) >y = float((a - (x - z)) + (b - z)) > > // Dekker's algorithm requires that |a| >= |b| > function [x; y] = FastTwoSum_Dekker(a; b) >x = float(a + b) >y = float((a - x) + b) > > Using the DF1 topology that you posted earlier: > > http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif > > I calculate that the error signal could be recovered for aproximately 30 > additional single-precision floating point additions (!) (there are 5 > acumulator operations using TwoSum_Knuth, plus another 5 normal additions to > accumulate the error). > > Seems pretty expensive. Perhaps there is a cheaper FiveSum_Knuth() that we > don't know about. Or maybe some assumptions can be made to allow use of > Dekker's algorithm. > > Ross. > > [1] Stef Graillat, Accurate Floating Point Product > http://www-pequan.lip6.fr/~graillat/papers/REC08_Paper_Graillat.pdf > -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Without any real thought, a few fun tests for a static topology are: 1. Time series error analysis as andy presented 2. Plot of error between expected response and actual response, for a set of frequencies across the spectrum, with long time-averaged measurements (what an audio precision would give you) 3. Thd+n by frequency of input sinewave 4. How close to the unit circle can you get a pole with your filter actually remaining stable (by frequency)? 5. Limit cycles. 6. Coefficient quantisation issues. Trickier to measure these days, but graphs of the quantized pole distributions for a low bit depth implementation are always intriguing, no? 7. It's always fun to play with a 4bit fixed point implementation of a topology just to see what it does! Dave. On Thursday, November 14, 2013, Lubomir I. Ivanov wrote: > On 14 November 2013 16:50, Ross Bencina > > > wrote: > > On 15/11/2013 1:20 AM, Lubomir I. Ivanov wrote: > >> > >> here is also the kohan algorithm: > >> http://en.wikipedia.org/wiki/Kahan_summation_algorithm > >> > >> to me it looks like it does 4 flops per accumulation. > > > > > > That's better. And one of those ops is always needed for any type of > > accumulation. So it adds 14 ops to Nigel's first-order error compensated > DF1 > > (the subtraction to compute the error in Nigel's diagram isn't needed). > > > > Now, what's the best way to evaluate the numerical performance of an > > implementation? > > > > by numerical performance i'm assuming estimating error, > > i'm not sure, i will probably use the common percentage error, based > on absolute difference... > > first, fill a data set with high precision/accurate values (e.g. > 64-bit double), preferably with high exponents, but to conform with > the target data type (e.g 32-bit single). > > De = (|Vt - Vhp| / Vhp) * 100; > > - De is the error delta > - Vt is the tested value post summation > - Vhp is the high precision value > > and then calculate mean for the data set for this particular algorithm. > > but, probably people familiar with numerical analysis will have > something better in mind. > i think some of the PDF's posted earlier had some of that. > > lubomir > -- > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 14 November 2013 16:50, Ross Bencina wrote: > On 15/11/2013 1:20 AM, Lubomir I. Ivanov wrote: >> >> here is also the kohan algorithm: >> http://en.wikipedia.org/wiki/Kahan_summation_algorithm >> >> to me it looks like it does 4 flops per accumulation. > > > That's better. And one of those ops is always needed for any type of > accumulation. So it adds 14 ops to Nigel's first-order error compensated DF1 > (the subtraction to compute the error in Nigel's diagram isn't needed). > > Now, what's the best way to evaluate the numerical performance of an > implementation? > by numerical performance i'm assuming estimating error, i'm not sure, i will probably use the common percentage error, based on absolute difference... first, fill a data set with high precision/accurate values (e.g. 64-bit double), preferably with high exponents, but to conform with the target data type (e.g 32-bit single). De = (|Vt - Vhp| / Vhp) * 100; - De is the error delta - Vt is the tested value post summation - Vhp is the high precision value and then calculate mean for the data set for this particular algorithm. but, probably people familiar with numerical analysis will have something better in mind. i think some of the PDF's posted earlier had some of that. lubomir -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 15/11/2013 1:20 AM, Lubomir I. Ivanov wrote: here is also the kohan algorithm: http://en.wikipedia.org/wiki/Kahan_summation_algorithm to me it looks like it does 4 flops per accumulation. That's better. And one of those ops is always needed for any type of accumulation. So it adds 14 ops to Nigel's first-order error compensated DF1 (the subtraction to compute the error in Nigel's diagram isn't needed). Now, what's the best way to evaluate the numerical performance of an implementation? From the Wikipedia page: "Algebraically, c should always be zero. Beware overly-aggressive optimizing compilers!" Beware of compiler writers who think floating point has anything to do with algebra over the Reals! Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 14 November 2013 16:20, Lubomir I. Ivanov wrote: > On 14 November 2013 14:56, Ross Bencina wrote: >> I calculate that the error signal could be recovered for aproximately 30 >> additional single-precision floating point additions (!) (there are 5 >> acumulator operations using TwoSum_Knuth, plus another 5 normal additions to >> accumulate the error). >> >> Seems pretty expensive. Perhaps there is a cheaper FiveSum_Knuth() that we >> don't know about. Or maybe some assumptions can be made to allow use of >> Dekker's algorithm. >> > > here is also the kohan algorithm: > http://en.wikipedia.org/wiki/Kahan_summation_algorithm > *kahan lubomir -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 14 November 2013 14:56, Ross Bencina wrote:
> I calculate that the error signal could be recovered for aproximately 30
> additional single-precision floating point additions (!) (there are 5
> acumulator operations using TwoSum_Knuth, plus another 5 normal additions to
> accumulate the error).
>
> Seems pretty expensive. Perhaps there is a cheaper FiveSum_Knuth() that we
> don't know about. Or maybe some assumptions can be made to allow use of
> Dekker's algorithm.
>
here is also the kohan algorithm:
http://en.wikipedia.org/wiki/Kahan_summation_algorithm
to me it looks like it does 4 flops per accumulation.
but as the article points out:
"In principle, a sufficiently aggressive optimizing compiler could
destroy the effectiveness of Kahan summation: for example, if the
compiler simplified expressions according to the associativity rules
of real arithmetic, it might "simplify" the second step in the
sequence t = sum + y; c = (t - sum) - y; to ((sum + y) - sum) - y;
then to c = 0;, eliminating the error compensation."
my quick ANSI C spin off:
-
/*
Kahan's sumation algorithm in ANSI C
*/
#include
#define FTfloat /* floating point type */
#define FS(x) x##f /* type suffix */
FT kahan_sum(const FT *vec, const int len)
{
int i = 0;
FT sum = FS(0.0), c = FS(0.0), y, t;
while (i < len) {
y = vec[i] - c;
t = sum + y;
c = (t - sum) - y;
sum = t;
i++;
}
return sum;
}
int main(void)
{
FT vec[3];
vec[0] = 0.9;
vec[1] = 0.1;
vec[2] = 0.9;
printf("%.11f, %.11f", vec[0] + vec[1] + vec[2], kahan_sum(vec, 3));
return 1;
}
-
lubomir
--
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 14 November 2013 15:26, Lubomir I. Ivanov wrote: > you can take a look at the algorithms FastTwoSum (by Neumaier based on > Dekker) and FastAccSum (it has variations). > actually it seems Neumaier reinvented the same algorithm. lubomir -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 14 November 2013 14:56, Ross Bencina wrote: > Hi Nigel, > > On 12/11/2013 8:52 PM, Nigel Redmon wrote: >> >> The problem is that the error is lost in the floating point >> hardware—you put in two floats and get back float of the same size. >> Something fell into a "bit bucket" that you don't have access to. > > > I figured that there must be some way to recover the error. > > After some research it turns out that there is something called "error free > transformation". This paper [1] gives two methods, one from Knuth AOPC vol 2 > p.236 (which unfortunately I don't own), and one by Dekker (1971): > > a and b are the numbers we'd like to sum. > x is the result. y is the rounding error (the bits that fell into the "bit > bucket" as you said above). > > From the paper: > > function [x; y] = TwoSum_Knuth(a; b) > x = float(a + b) > z = float(x - a) > y = float((a - (x - z)) + (b - z)) > > // Dekker's algorithm requires that |a| >= |b| > function [x; y] = FastTwoSum_Dekker(a; b) > x = float(a + b) > y = float((a - x) + b) > > Using the DF1 topology that you posted earlier: > > http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif > > I calculate that the error signal could be recovered for aproximately 30 > additional single-precision floating point additions (!) (there are 5 > acumulator operations using TwoSum_Knuth, plus another 5 normal additions to > accumulate the error). > > Seems pretty expensive. Perhaps there is a cheaper FiveSum_Knuth() that we > don't know about. Or maybe some assumptions can be made to allow use of > Dekker's algorithm. > > Ross. > > [1] Stef Graillat, Accurate Floating Point Product > http://www-pequan.lip6.fr/~graillat/papers/REC08_Paper_Graillat.pdf > here are a couple of papers by SIEGFRIED M. RUMP, that may be of interest. [1] http://www.ti3.tu-harburg.de/paper/rump/Ru08b.pdf [2] http://www.ti3.tu-harburg.de/paper/rump/Ru09.pdf you can take a look at the algorithms FastTwoSum (by Neumaier based on Dekker) and FastAccSum (it has variations). lubomir -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Hi Nigel, On 12/11/2013 8:52 PM, Nigel Redmon wrote: The problem is that the error is lost in the floating point hardware—you put in two floats and get back float of the same size. Something fell into a "bit bucket" that you don't have access to. I figured that there must be some way to recover the error. After some research it turns out that there is something called "error free transformation". This paper [1] gives two methods, one from Knuth AOPC vol 2 p.236 (which unfortunately I don't own), and one by Dekker (1971): a and b are the numbers we'd like to sum. x is the result. y is the rounding error (the bits that fell into the "bit bucket" as you said above). From the paper: function [x; y] = TwoSum_Knuth(a; b) x = float(a + b) z = float(x - a) y = float((a - (x - z)) + (b - z)) // Dekker's algorithm requires that |a| >= |b| function [x; y] = FastTwoSum_Dekker(a; b) x = float(a + b) y = float((a - x) + b) Using the DF1 topology that you posted earlier: http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif I calculate that the error signal could be recovered for aproximately 30 additional single-precision floating point additions (!) (there are 5 acumulator operations using TwoSum_Knuth, plus another 5 normal additions to accumulate the error). Seems pretty expensive. Perhaps there is a cheaper FiveSum_Knuth() that we don't know about. Or maybe some assumptions can be made to allow use of Dekker's algorithm. Ross. [1] Stef Graillat, Accurate Floating Point Product http://www-pequan.lip6.fr/~graillat/papers/REC08_Paper_Graillat.pdf -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
I sellotaped a bag underneath an old behringer mixer, and now it sounds like an early Neve. My greatest regret is that I didn't make that website. It's poe's law. I suspect the owner is on here somewhere. Use the power of quantum mechanics to improve your audio! Dave. On Wednesday, November 13, 2013, STEFFAN DIEDRICHSEN wrote: > You just need to convince SPICE to leave out components connected to > identical nodes …. > > ;-) > > Steffan > > On 13.11.2013, at 13:08, Dave Gamble > > wrote: > > > Oh yeah? > > > > Well you'll never be able to model these! > > http://www.machinadynamica.com/machina31.htm > > > > /sarcasm > > :D > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
You just need to convince SPICE to leave out components connected to identical nodes …. ;-) Steffan On 13.11.2013, at 13:08, Dave Gamble wrote: > Oh yeah? > > Well you'll never be able to model these! > http://www.machinadynamica.com/machina31.htm > > /sarcasm > :D -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Oh yeah? Well you'll never be able to model these! http://www.machinadynamica.com/machina31.htm /sarcasm :D On Wednesday, November 13, 2013, STEFFAN DIEDRICHSEN wrote: > > On 13.11.2013, at 12:54, Vadim Zavalishin < > vadim.zavalis...@native-instruments.de > wrote: > > > So, after we have modelled them all, we are not gonna need any further > modelling. > > ;-) > > At that time,we should offer real-time spice to let our dear customers > tinker with their virtual circuits. We’ll offer in-app purchases like > “bumble bee paper wax caps” or “snake oil inductors”. > > Steffan > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Lubomir I. Ivanov wrote: On 6 November 2013 11:45, Andrew Simper wrote: ... actually trapezoidal is all over quantum mechanics because, say in comparison to midpoint you will get those control and state variable intermediates that mess calculation quite badly in cases that you can't really handle them in massively complicated models. in quantized signal DSP (which is also a widely approximating field in itself) we can play more with that because we get slightly more of the freedom and certainty. Sure you're not implying similarity between the Heisenberg functional integral in Fock space and the sinc (sin(t)/t) function as a sample reconstruction, and confusing time and amplitude quantization all in one sentence ?!? T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 6 November 2013 11:45, Andrew Simper wrote: > Here is an updated version of the optimised trapezoidal integrated svf > which bundles up all previous state into equivalent currents for the > capacitors, which is how I solve non-linear circuits (although this > solution is just the linear one that I'm posting here). The only thing > to note that with trapezoidal integration you have gain terms of g = > tan(pi*cutoff/samplerate) which become very large with high cutoff, so > care needs to be taken if these "g" terms stand alone since the > scaling can get large and could impact numerical performance: > > http://www.cytomic.com/files/dsp/SvfLinearTrapOptimised2.pdf > > Here is a similar thing done for a Sallen Key low pass: > > http://www.cytomic.com/files/dsp/SkfLinearTrapOptimised2.pdf > > Please note there is absolutely nothing new here, this is all standard > circuit maths that has been around for ages, and all the maths behind > it was invented by people like Netwon, Leibnitz, and Euler, they > deserve all the credit and came up with ways of solving not just this > linear case but also the non-linear case. Depending on what you are > doing trapezoidal may not be the best integrator to use so most > systems of solving these equations support several types of > integrator. Here are some handy references: > > http://en.wikipedia.org/wiki/Capacitor > http://en.wikipedia.org/wiki/Nodal_analysis > http://qucs.sourceforge.net/tech/node26.html > http://www.ecircuitcenter.com/SPICEtopics.htm > > Please let me know if there are any mistakes. Enjoy! > mostly ignoring the tangential properties of the thread, i like the implementation, and i value the choice of trapezoidal approximation here and how the "kirchhoff equality" calculations are explained. while i haven't played with this approach, the digital filters seems *quite* stable and accurate (particulary for the SVF case in comparison to other derivatives). also, i don't think that the linear interpolation for the integral approximation is that much of a bad trade off here and it will also not affect stability. perhaps, quadratic can be considered, but that will surely insert state variable changes tick wise. you may have given that a try already... actually trapezoidal is all over quantum mechanics because, say in comparison to midpoint you will get those control and state variable intermediates that mess calculation quite badly in cases that you can't really handle them in massively complicated models. in quantized signal DSP (which is also a widely approximating field in itself) we can play more with that because we get slightly more of the freedom and certainty. can't fault it on a larger scale and it has everything in the paper (+ source code), so... lubomir -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12.11.2013, at 10:16, Vadim Zavalishin wrote: > It's very easy. As I mentioned in my other email, switching from float to > double halves the number of available SIMD channels, which means you need to > run your code twice as many times. Right. But with the advent of AVX with about 512 bit wide registers, situation changes a bit. > On the other hand, in my experience, most of the DSP algorithms are quite > tolerant to using 32-bit floats (DF filters being one exception). This depends on the center frequency region. E.g. if you take a bilinear transformed band pass filter with one biquad, the FIR part is always [a0, 0.0, -a0], which is a static band pass at fs/4. The conjugate pole pair needs to create a large hump / resonance to “compensate” this static band pass to achieve the desired frequency response. At very low frequencies (fc < fs * 0.01 )and high frequencies (fc ~ fs/2), this leads to an enormous precision loss with noisy results. Exchanging FIR and IIR part (DF1 -> DF2 and going further to DF2T) leads to the effect, that the noise is filtered by the FIR part. In this regard, the SVF behaves much better. All-pole-filters rulez! Steffan -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
As an alternative perspective on this, consider the idea that creating a shipping piece of DSP code requires two (hopefully) distinct phases- 1. Understanding what you're doing, and making it work. 2. Optimising it for a production environment. I claim that introducing SIMD in 1 is just over complicating the issue. As for what effect it has in 2, I'd expect that to be entirely context dependent; but I'm not talking about that. When learning new things, part 2 simply does not factor in. Part 1 should be double precision. Considering whether you can optimise your code to use single is something for part2. I think Andy's numerical precision graphs for the different topologies are FASCINATING, and you won't get far with DF if you're trying to model nonlinearities or modulating coefficients; you'll want a new topology. But this is still all part 1. If everyone disagrees with me, I'll knock up the double precision analysis graphs and post them myself, as time permits, and everyone is welcome to ignore them. Perhaps this is only interesting to me, but even if Andy's rearrangements had TERRIBLE numerical performance, you would still need to use them for modulated/nonlinear scenarios. But the proliferation of single precision conflates things to conceal this fact. Start with double precision, know the numerical behaviour of your process, and apply judicious and directed optimisation using that knowledge. Starting with single precision is like tying your wrists together before you start typing. Dave. On Tuesday, November 12, 2013, Didier Dambrin wrote: > IMHO, a piece of DSP code is generally used in something else, rarely on > its own. Whether it ends up as part of a bigger project or in a plugin, > it'd better not waste CPU. > > All I know is that SIMD is made for DSP, & whether it's sound or image > processing it's where most of the CPU goes, so if someone's app "spends > only 2% in vector code", there's a problem.. > > This said, I would too use doubles for filtering, it's common to process > stereo streams through SSE2, but if I had lots of parallel streams to > filter, I would seriously consider singles, as long as packing/unpacking > isn't more costy than the benefits of course. > > > > > -Message d'origine----- From: Dave Gamble > Sent: Tuesday, November 12, 2013 10:40 AM > To: A discussion list for music-related DSP > Subject: Re: [music-dsp] Trapezoidal integrated optimised SVF v2 > > Hi, > > On Tuesday, November 12, 2013, Vadim Zavalishin wrote: > > On 12-Nov-13 10:10, Dave Gamble wrote: >> >> So let me go out on a limb here: if you take some single precision code >>> and >>> up it to double, and things get WORSE then there is something very >>> strange >>> about your original code that merits investigation. >>> >>> >> It's very easy. As I mentioned in my other email, switching from float to >> double halves the number of available SIMD channels, which means you need >> to run your code twice as many times. On the other hand, in my experience, >> most of the DSP algorithms are quite tolerant to using 32-bit floats (DF >> filters being one exception). >> >> Changing from single precision SIMD to double precision is a little more >> > work than just changing your declared data type. > > I'm not sure your example really fits the spirit of what I'm saying. > > Even if the majority of filter implementations in the world were SIMD, > which is very hard to believe, it would still, as a general rule, be safer > for newcomers to use double precision, and analyses showing double > precision would thus have practical utility. > > On the other hand, if you have access to a pool of graduates coming into > the field who have pre-existing SIMD experience, you're a phenomenally > lucky guy! But if those graduates start by coding things up as SIMD, your > situation might not be so rosy! > > Dave. > > > > -- >> Vadim Zavalishin >> Reaktor Application Architect >> Native Instruments GmbH >> +49-30-611035-0 >> >> www.native-instruments.com >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp >> >> -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > >
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
IMHO, a piece of DSP code is generally used in something else, rarely on its own. Whether it ends up as part of a bigger project or in a plugin, it'd better not waste CPU. All I know is that SIMD is made for DSP, & whether it's sound or image processing it's where most of the CPU goes, so if someone's app "spends only 2% in vector code", there's a problem.. This said, I would too use doubles for filtering, it's common to process stereo streams through SSE2, but if I had lots of parallel streams to filter, I would seriously consider singles, as long as packing/unpacking isn't more costy than the benefits of course. -Message d'origine- From: Dave Gamble Sent: Tuesday, November 12, 2013 10:40 AM To: A discussion list for music-related DSP Subject: Re: [music-dsp] Trapezoidal integrated optimised SVF v2 Hi, On Tuesday, November 12, 2013, Vadim Zavalishin wrote: On 12-Nov-13 10:10, Dave Gamble wrote: So let me go out on a limb here: if you take some single precision code and up it to double, and things get WORSE then there is something very strange about your original code that merits investigation. It's very easy. As I mentioned in my other email, switching from float to double halves the number of available SIMD channels, which means you need to run your code twice as many times. On the other hand, in my experience, most of the DSP algorithms are quite tolerant to using 32-bit floats (DF filters being one exception). Changing from single precision SIMD to double precision is a little more work than just changing your declared data type. I'm not sure your example really fits the spirit of what I'm saying. Even if the majority of filter implementations in the world were SIMD, which is very hard to believe, it would still, as a general rule, be safer for newcomers to use double precision, and analyses showing double precision would thus have practical utility. On the other hand, if you have access to a pool of graduates coming into the field who have pre-existing SIMD experience, you're a phenomenally lucky guy! But if those graduates start by coding things up as SIMD, your situation might not be so rosy! Dave. -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp - Aucun virus trouve dans ce message. Analyse effectuee par AVG - www.avg.fr Version: 2012.0.2242 / Base de donnees virale: 3222/6328 - Date: 11/11/2013 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On Tue, 12 Nov 2013 10:40:25 +0200, Tim Blechmann wrote: well, when benchmarking my performance code, about 2% of the CPU time is spent in vector code, while about 60% is spent in scalar filter code. of course one can run 4 parallel single-precision filters or 2 double-precision filters with SSE, but there are few use cases for 4-channel filters. I think a synth with four or more voices is a pretty good example of one. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
>>> One word: SIMD >> >> well, when benchmarking my performance code, about 2% of the CPU time is >> spent in vector code, while about 60% is spent in scalar filter code. > > Hi Tim > > I can't believe vector code is running 30 times faster than the scalar > code :-D :-D :-D scalar/vector parts of the same program though i've already seen some code that runs more than 15 times faster in vector code than in scalar (avoiding branches, ooo engine not waiting for unused results of expensive operations etc) > Seriously speaking, this ratio very much depends on the details of the > software. It might as well be that you have no scalar filter code at all. true. however as a rule of thumb i figured out that once filters enter the game, they govern most benchmarks. for highly vectorizable code (ambisonic panners, mixing, non-linear distortion) i'm sure single-precision is more efficient than double-precision. but tbo i was quite surprised to see how cheap all these operations are compared to (especially non-linear) filters. cheers, tim signature.asc Description: OpenPGP digital signature -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
> In some cases error feedback methods for floating point would be interesting > if they exist. The problem is that the error is lost in the floating point hardware—you put in two floats and get back float of the same size. Something fell into a "bit bucket" that you don't have access to. Fortunately, as Dave points out, double precision *usually* gets us close enough, especially if we pick a suitable algorithm. Of course, the alternative is to roll your own, whether fixed or floating point. (This reminds me of when I had to reverse-engineer a clever early '80s piece of medical lab equipment for a patent case…it pre-dated IEEE floating point, and they had rolled their own, running on an 8-bit micro; good thing the processing didn't need to be real time! Since they already knew the signs of the multipliers and results, they didn't even bother wasting a bit for sign—just either added or subtracted the result as needed. Their math subroutines weren't general, but they did exactly what was needed.) On Nov 12, 2013, at 1:33 AM, Ross Bencina wrote: > On 12/11/2013 8:07 PM, Nigel Redmon wrote: >> The exact answer depends on the exact hardware. It's pretty trivial >> on the 56k, of course (the 56-bit accumultor works automatically with >> the MAC instruction, quantization happens automatically when saving >> to 24-bit, just take the difference and feed it back for the noise >> shaping). If you're talking about doing it on floating point, where >> the result of every multiply (and some additions, especially tiny + >> huge) is a quantization, it's a much messier issue. On your typically >> CPU, we use double precision, of course, and forget about it (I'd >> still pay attention to numerical properties, though the DP makes that >> not as important). If you're talking about a processor with single >> precision FP only…I'd pick an algorithm with better numerical >> properties than the DF1 (the transposed DF2 would be my choice of the >> direct forms), and hope that was good enough. > > Hi Nigel, > > That's what I suspected. > > I recently had a non-audio control application where I needed a very high > precision lowpass filter. I needed very low quantization noise using double > precision floats (x86 and ARM). I ended up using Andy's SVF and it worked a > lot better than DF1 or DF2. I didn't try transposed DF2. > > In some cases error feedback methods for floating point would be interesting > if they exist. > > Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Hi, On Tuesday, November 12, 2013, Vadim Zavalishin wrote: > On 12-Nov-13 10:10, Dave Gamble wrote: > >> So let me go out on a limb here: if you take some single precision code >> and >> up it to double, and things get WORSE then there is something very strange >> about your original code that merits investigation. >> > > It's very easy. As I mentioned in my other email, switching from float to > double halves the number of available SIMD channels, which means you need > to run your code twice as many times. On the other hand, in my experience, > most of the DSP algorithms are quite tolerant to using 32-bit floats (DF > filters being one exception). > > Changing from single precision SIMD to double precision is a little more work than just changing your declared data type. I'm not sure your example really fits the spirit of what I'm saying. Even if the majority of filter implementations in the world were SIMD, which is very hard to believe, it would still, as a general rule, be safer for newcomers to use double precision, and analyses showing double precision would thus have practical utility. On the other hand, if you have access to a pool of graduates coming into the field who have pre-existing SIMD experience, you're a phenomenally lucky guy! But if those graduates start by coding things up as SIMD, your situation might not be so rosy! Dave. > -- > Vadim Zavalishin > Reaktor Application Architect > Native Instruments GmbH > +49-30-611035-0 > > www.native-instruments.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12/11/2013 8:07 PM, Nigel Redmon wrote: The exact answer depends on the exact hardware. It's pretty trivial on the 56k, of course (the 56-bit accumultor works automatically with the MAC instruction, quantization happens automatically when saving to 24-bit, just take the difference and feed it back for the noise shaping). If you're talking about doing it on floating point, where the result of every multiply (and some additions, especially tiny + huge) is a quantization, it's a much messier issue. On your typically CPU, we use double precision, of course, and forget about it (I'd still pay attention to numerical properties, though the DP makes that not as important). If you're talking about a processor with single precision FP only…I'd pick an algorithm with better numerical properties than the DF1 (the transposed DF2 would be my choice of the direct forms), and hope that was good enough. Hi Nigel, That's what I suspected. I recently had a non-audio control application where I needed a very high precision lowpass filter. I needed very low quantization noise using double precision floats (x86 and ARM). I ended up using Andy's SVF and it worked a lot better than DF1 or DF2. I didn't try transposed DF2. In some cases error feedback methods for floating point would be interesting if they exist. Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12-Nov-13 10:10, Dave Gamble wrote: So let me go out on a limb here: if you take some single precision code and up it to double, and things get WORSE then there is something very strange about your original code that merits investigation. It's very easy. As I mentioned in my other email, switching from float to double halves the number of available SIMD channels, which means you need to run your code twice as many times. On the other hand, in my experience, most of the DSP algorithms are quite tolerant to using 32-bit floats (DF filters being one exception). -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On Tuesday, November 12, 2013, Vadim Zavalishin wrote: > On 12-Nov-13 10:01, Dave Gamble wrote: > >> Because switching from double to float will bring extremely small >> performance gains in CPU cost, and potentially sizeable problems with >> numerical issues. >> > > I'd be very careful with statements like that. There are people with > exactly the opposite experience. YMMV ;-) > > But that's exactly the statement I intend to defend. If improving your accuracy brings you accuracy problems, something phenomenally strange has happened. And when switching from float to double brings dramatic changes to your CPU cost, that in itself makes things worth investigating. So let me go out on a limb here: if you take some single precision code and up it to double, and things get WORSE then there is something very strange about your original code that merits investigation. I'm extremely interested to hear of any cases where someone has has the opposite experience, as Vadim puts it. Dave. -- > Vadim Zavalishin > Reaktor Application Architect > Native Instruments GmbH > +49-30-611035-0 > > www.native-instruments.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Hi Ross, The exact answer depends on the exact hardware. It's pretty trivial on the 56k, of course (the 56-bit accumultor works automatically with the MAC instruction, quantization happens automatically when saving to 24-bit, just take the difference and feed it back for the noise shaping). If you're talking about doing it on floating point, where the result of every multiply (and some additions, especially tiny + huge) is a quantization, it's a much messier issue. On your typically CPU, we use double precision, of course, and forget about it (I'd still pay attention to numerical properties, though the DP makes that not as important). If you're talking about a processor with single precision FP only…I'd pick an algorithm with better numerical properties than the DF1 (the transposed DF2 would be my choice of the direct forms), and hope that was good enough. Nigel On Nov 12, 2013, at 12:26 AM, Ross Bencina wrote: > On 12/11/2013 5:47 PM, Nigel Redmon wrote: >> For anyone interested, here's the block diagram: >> http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif (from this >> article: http://www.earlevel.com/main/2003/02/28/biquads/ ). "Q", the >> quantized output, is simply the output of the accumulator (the >> central "+") at reduced resolution (in 56k, the accumulator is 56 >> bits, but the unit delays are 24-bit, and we're doing 24x24 MACs >> anyway). So the difference between the accumulator and the quantized >> output is the error, the amount that was lost in the quantization >> step, and that gets fed back via the delay. > > Hi Nigel, > > That's interesting. > > Do you know if there's a way to do this without using a double-precision > accumulator? > > Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12-Nov-13 10:01, Dave Gamble wrote: Because switching from double to float will bring extremely small performance gains in CPU cost, and potentially sizeable problems with numerical issues. I'd be very careful with statements like that. There are people with exactly the opposite experience. YMMV ;-) -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Heya, On Tuesday, November 12, 2013, Vadim Zavalishin wrote: > On 12-Nov-13 09:53, Dave Gamble wrote: > >> PS. "Time-varying performance" is another word. "Nonlinearities" is the >>> third one. >>> >> >> Not criticisms I'm at all familiar with, I'm afraid. Can you expand? >> > > As we are talking about inferiority of DF compared to ZDF, I just > mentioned the other two, which are even way more prominent than the > quantization issues, as they can't be addressed by switching to 64 bit > floats (but they already have been mentioned multiple times in the scope of > the present discussion). DF has very poor time-varying (modulated > parameters) performance and is absolutely uncapable of properly hosting the > nonlinearities present in the original analog prototype. > > No disagreement there- I'm not arguing against ZDF or for DF. I'm being entirely tangential to that part of the debate. Sorry if that wasn't clear. I'm simply making a plea for inclusion of double precision numerical performance comparisons. I'm trying to argue that they're actually more /practically/ useful than fixed point or floating point analyses. Looks like I'm not being as clear as I ought. Apologies. Dave. > Regards, > Vadim > > -- > Vadim Zavalishin > Reaktor Application Architect > Native Instruments GmbH > +49-30-611035-0 > > www.native-instruments.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Heya, On Tuesday, November 12, 2013, Nigel Redmon wrote: > All true, Dave, and I mostly agree with your sentiment. But the > context…the subject was DF1 and its numerical properties compared to > others. So sure, you can say throw double precision at anything, but it > doesn't change the fact its numerical properties are inferior to other > choices. And it's a bit of a different deal with floating point. Which is > why I mentioned that I'd use transposed DF2 for floating point—I wouldn't > use DF1 for anything, assuming I never have to write or modify 56k code > again. But to be clear, I'd use DF1, in double precision, if there were a > reason—there just isn't, in my mind. And by this point, the whole subject > is probably past apple and oranges and into fruit punch ;-) > > This is exactly it. The fact that X has better numerical performance than Y with arbitrary restriction Z might well prove irrelevant when arbitrary restriction Z is removed. I'm just asking that we use a better arbitrary restriction Z for the analyses which is closer to real world use. If there IS one rule of thumb we can offer to people coming into this field, it is this: Unless you are an assembly language-coding optimizing demon, use double precision and a whole heap of your problems vanish. Because switching from double to float will bring extremely small performance gains in CPU cost, and potentially sizeable problems with numerical issues. Dave. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12-Nov-13 09:53, Dave Gamble wrote: Absolutely! SSE2, which by all the stats I've seen is entirely ubiquitous now, is double precision, and has been since 2004, which is close enough to a decade for my taste. http://en.wikipedia.org/wiki/SSE2 Well, you get only half the number of available channels with SSE if you use doubles. If 2 channels are sufficient for you, then you might not care, of course. -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12-Nov-13 09:53, Dave Gamble wrote: PS. "Time-varying performance" is another word. "Nonlinearities" is the third one. Not criticisms I'm at all familiar with, I'm afraid. Can you expand? As we are talking about inferiority of DF compared to ZDF, I just mentioned the other two, which are even way more prominent than the quantization issues, as they can't be addressed by switching to 64 bit floats (but they already have been mentioned multiple times in the scope of the present discussion). DF has very poor time-varying (modulated parameters) performance and is absolutely uncapable of properly hosting the nonlinearities present in the original analog prototype. Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On Tuesday, November 12, 2013, Vadim Zavalishin wrote: > On 12-Nov-13 09:05, Dave Gamble wrote: > >> Actually, I'll go one further: In 2013, single precision is just time >> wasting. It's a pathological case for analysis, but it shouldn't represent >> real-world usage. >> >> I'm reminded of a conversation I had with my PhD supervisor 12 years ago, >> when showing him some source which caused him to remark "single precision? >> What is this? 1980?". >> > > One word: SIMD > > Absolutely! SSE2, which by all the stats I've seen is entirely ubiquitous now, is double precision, and has been since 2004, which is close enough to a decade for my taste. http://en.wikipedia.org/wiki/SSE2 > PS. "Time-varying performance" is another word. "Nonlinearities" is the > third one. Not criticisms I'm at all familiar with, I'm afraid. Can you expand? Dave. > > -- > Vadim Zavalishin > Reaktor Application Architect > Native Instruments GmbH > +49-30-611035-0 > > www.native-instruments.com > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12-Nov-13 09:40, Tim Blechmann wrote: One word: SIMD well, when benchmarking my performance code, about 2% of the CPU time is spent in vector code, while about 60% is spent in scalar filter code. Hi Tim I can't believe vector code is running 30 times faster than the scalar code :-D :-D :-D Seriously speaking, this ratio very much depends on the details of the software. It might as well be that you have no scalar filter code at all. Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12/11/2013 7:40 PM, Tim Blechmann wrote: some real-world benchmarks from the csound community imply a performance difference of roughly 10% [1]. Csound doesn't have a facility for running multiple filters in parallel though does it? not even 2 in parallel for stereo. 4 biquads in parallel can be useful if you have a higher-order filter you can factor (granted not so useful for non-linear stuff). Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
All true, Dave, and I mostly agree with your sentiment. But the context…the subject was DF1 and its numerical properties compared to others. So sure, you can say throw double precision at anything, but it doesn't change the fact its numerical properties are inferior to other choices. And it's a bit of a different deal with floating point. Which is why I mentioned that I'd use transposed DF2 for floating point—I wouldn't use DF1 for anything, assuming I never have to write or modify 56k code again. But to be clear, I'd use DF1, in double precision, if there were a reason—there just isn't, in my mind. And by this point, the whole subject is probably past apple and oranges and into fruit punch ;-) In the end we choose the filters that do the job, and pay attention to the cycles it takes. More so when the processing is sample-by-sample and when the CPU and its speed are set in stone and so is your choice of fixed/float (legacy Pro Tools TDM; there I chose single precision fixed, single precision with noise shaping, and 24x48 as needed—but never full double precision. It was way too costly, especially considering the plug-ins where about filtering explicitly). I know that your focus is EQ (maybe other things—just going by what I've seen on kvraudio), so yes, I would expect precision to be everything for you, and cycles not so much. But even in this day and age, the cycles still mean something for heavyweight plug-ins like synths—which is why some (Urs' stuff, for instance) have multiple quality modes (including draft). (And, "12 years ago"…I wonder if your PhD supervisor ever had to ship a real, state of the art, DSP application that had to run in so called "real time" ;-) I know I was still counting cycles for TDM pluggies back then.) On Nov 12, 2013, at 12:05 AM, Dave Gamble wrote: > While I think of it, could I just throw in that double precision analysis > is MUCH more interesting to anyone implementing on a modern CPU? > > For embedded stuff, single precision and fixed are obviously the big > options (though I can't remember when/why I would have tried implementing a > non-double-precision-fixed IIR on a 56k if it needed to be in the audio > path. Use your DMAC.), but on a modern intel, there's really very little > incentive to stick with single precision when all the hardware > implementations around appear to be double now. > > Actually, I'll go one further: In 2013, single precision is just time > wasting. It's a pathological case for analysis, but it shouldn't represent > real-world usage. > > I'm reminded of a conversation I had with my PhD supervisor 12 years ago, > when showing him some source which caused him to remark "single precision? > What is this? 1980?". > > Dave. > > On Tuesday, November 12, 2013, Nigel Redmon wrote: > >> Andy makes a good point—DF1 is indeed pretty poor, extremely sensitive to >> quantization error at the low end. With 24-bit fixed point, 56-bit >> accumulation of the moto/freescale family, which I know Robert is extremely >> familiar with, and a natural for implementing DF1, it's still not good >> enough for audio without error shaping. I've done both first and second >> order, and first order was certainly adequate for what I ever needed, a >> huge improvement for very little cost. But as Andy said, that doesn't mean >> that DF1 performance is not poor numerically, at the low end anyway. (But >> for floating point I'd use transposed DF2.) >> >> For anyone interested, here's the block diagram: >> http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif (from this >> article: http://www.earlevel.com/main/2003/02/28/biquads/ ). "Q", the >> quantized output, is simply the output of the accumulator (the central "+") >> at reduced resolution (in 56k, the accumulator is 56 bits, but the unit >> delays are 24-bit, and we're doing 24x24 MACs anyway). So the difference >> between the accumulator and the quantized output is the error, the amount >> that was lost in the quantization step, and that gets fed back via the >> delay. >> >> >> On Nov 11, 2013, at 6:29 PM, Andrew Simper wrote: >> >>> On 11 November 2013 08:09, robert bristow-johnson >>> wrote: On 11/8/13 6:47 PM, Andrew Simper wrote: > > On 9 November 2013 08:57, Tom Duffy wrote: >> >> Having worked with Direct-Form I filters for half of my >> career, I've been glossing over this discussion as >> not relevant to me. > > It depends if you value numerical performance, cutoff accuracy, dc > performance etc etc, DF1 scores badly on all these fronts, nope. >>> >>> Actually yep. Whenever I mentioned DF1 I meant DF1, not DF1 with added >>> and noise shaping. I'm using the algorithms you published in your RBJ >>> audio eq cookbook, I could see no mention of noise shaping there, nor >>> using a mapping from cos to sin to help out in the text that you >>> wrote, not even as a one line disclaimer saying: "oh and watch out for >>>
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
>> Actually, I'll go one further: In 2013, single precision is just time >> wasting. It's a pathological case for analysis, but it shouldn't >> represent >> real-world usage. >> >> I'm reminded of a conversation I had with my PhD supervisor 12 years ago, >> when showing him some source which caused him to remark "single >> precision? >> What is this? 1980?". > > One word: SIMD well, when benchmarking my performance code, about 2% of the CPU time is spent in vector code, while about 60% is spent in scalar filter code. of course one can run 4 parallel single-precision filters or 2 double-precision filters with SSE, but there are few use cases for 4-channel filters. some real-world benchmarks from the csound community imply a performance difference of roughly 10% [1]. > PS. "Time-varying performance" is another word. "Nonlinearities" is the > third one. in my own benchmarks of a time-varying nonlinear filter with a single-precision external interface and double-precision internal processing showed no measurable performance difference compared to the version with single-precision. cheers, tim [1] http://ruccas.org/pub/Gogins/csoundabx.pdf signature.asc Description: OpenPGP digital signature -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12/11/2013 5:47 PM, Nigel Redmon wrote: For anyone interested, here's the block diagram: http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif (from this article: http://www.earlevel.com/main/2003/02/28/biquads/ ). "Q", the quantized output, is simply the output of the accumulator (the central "+") at reduced resolution (in 56k, the accumulator is 56 bits, but the unit delays are 24-bit, and we're doing 24x24 MACs anyway). So the difference between the accumulator and the quantized output is the error, the amount that was lost in the quantization step, and that gets fed back via the delay. Hi Nigel, That's interesting. Do you know if there's a way to do this without using a double-precision accumulator? Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12-Nov-13 09:05, Dave Gamble wrote: Actually, I'll go one further: In 2013, single precision is just time wasting. It's a pathological case for analysis, but it shouldn't represent real-world usage. I'm reminded of a conversation I had with my PhD supervisor 12 years ago, when showing him some source which caused him to remark "single precision? What is this? 1980?". One word: SIMD Regards, Vadim PS. "Time-varying performance" is another word. "Nonlinearities" is the third one. -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 12 November 2013 10:29, Andrew Simper wrote: > On 11 November 2013 08:09, robert bristow-johnson > wrote:> > > you can, for a lot fewer instructions than a lattice or a ladder or an > SVF, > > do a DF1 with noise shaping with a zero in the quantization noise TF at > z=1 > > that obliterates any DC error. infinite S/N at f=0. in a fixed-point > > context, this DF1 with noise shaping (sometimes called "fraction saving), > > has *one* quantization point, not two, not three. > > I don't believe you, so how about post some code so show it? Actually > I do believe you but I'm too lazy and completely un-motivated to work > through and double check a correct implementation of DF1 with noise > shaping, but I would love to add the results of this to all the plots > I've done so people can make a more informed decision when comparing > the different methods. > Hi Robert, I forgot to say, I'm after a 32 bit floating point implementation of a DF1 with noise shaped dither so I can compare it to other 32-bit float algorithms. All the best, Andy -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
While I think of it, could I just throw in that double precision analysis is MUCH more interesting to anyone implementing on a modern CPU? For embedded stuff, single precision and fixed are obviously the big options (though I can't remember when/why I would have tried implementing a non-double-precision-fixed IIR on a 56k if it needed to be in the audio path. Use your DMAC.), but on a modern intel, there's really very little incentive to stick with single precision when all the hardware implementations around appear to be double now. Actually, I'll go one further: In 2013, single precision is just time wasting. It's a pathological case for analysis, but it shouldn't represent real-world usage. I'm reminded of a conversation I had with my PhD supervisor 12 years ago, when showing him some source which caused him to remark "single precision? What is this? 1980?". Dave. On Tuesday, November 12, 2013, Nigel Redmon wrote: > Andy makes a good point—DF1 is indeed pretty poor, extremely sensitive to > quantization error at the low end. With 24-bit fixed point, 56-bit > accumulation of the moto/freescale family, which I know Robert is extremely > familiar with, and a natural for implementing DF1, it's still not good > enough for audio without error shaping. I've done both first and second > order, and first order was certainly adequate for what I ever needed, a > huge improvement for very little cost. But as Andy said, that doesn't mean > that DF1 performance is not poor numerically, at the low end anyway. (But > for floating point I'd use transposed DF2.) > > For anyone interested, here's the block diagram: > http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif (from this > article: http://www.earlevel.com/main/2003/02/28/biquads/ ). "Q", the > quantized output, is simply the output of the accumulator (the central "+") > at reduced resolution (in 56k, the accumulator is 56 bits, but the unit > delays are 24-bit, and we're doing 24x24 MACs anyway). So the difference > between the accumulator and the quantized output is the error, the amount > that was lost in the quantization step, and that gets fed back via the > delay. > > > On Nov 11, 2013, at 6:29 PM, Andrew Simper wrote: > > > On 11 November 2013 08:09, robert bristow-johnson > > wrote: > >> On 11/8/13 6:47 PM, Andrew Simper wrote: > >>> > >>> On 9 November 2013 08:57, Tom Duffy wrote: > > Having worked with Direct-Form I filters for half of my > career, I've been glossing over this discussion as > not relevant to me. > >>> > >>> It depends if you value numerical performance, cutoff accuracy, dc > >>> performance etc etc, DF1 scores badly on all these fronts, > >> > >> > >> nope. > > > > Actually yep. Whenever I mentioned DF1 I meant DF1, not DF1 with added > > and noise shaping. I'm using the algorithms you published in your RBJ > > audio eq cookbook, I could see no mention of noise shaping there, nor > > using a mapping from cos to sin to help out in the text that you > > wrote, not even as a one line disclaimer saying: "oh and watch out for > > using this, if you don't use double precision you will most likely > > need noise shaping to get reasonable audio performance". > > > > > >>> and this is even in the case where you keep your cutoff and q > unchanged. > >>> > >> > >> you can, for a lot fewer instructions than a lattice or a ladder or an > SVF, > >> do a DF1 with noise shaping with a zero in the quantization noise TF at > z=1 > >> that obliterates any DC error. infinite S/N at f=0. in a fixed-point > >> context, this DF1 with noise shaping (sometimes called "fraction > saving), > >> has *one* quantization point, not two, not three. > > > > I don't believe you, so how about post some code so show it? Actually > > I do believe you but I'm too lazy and completely un-motivated to work > > through and double check a correct implementation of DF1 with noise > > shaping, but I would love to add the results of this to all the plots > > I've done so people can make a more informed decision when comparing > > the different methods. > > > > Now lets have a look at a bell using DF1 or SVF trap: > > > > DF1 bell (5* 4+ 4=) > > const x0 = input > > const y0 = b0*x0 + b1*x1 + b2*x2 + a1*y1 + a2*y2 > > x2 = x1 > > x1 = x0 > > y2 = y1 > > y1 = y0 > > const output = y0 > > > > SVF Trap bell (6* 6+ 2=) > > const v0 = input > > const v1 = a0*v0 + a1*ic1eq + a2*ic2eq > > const v2 = ic2eq + g*v1 > > ic1eq = 2*v1 - ic1eq > > ic2eq = 2*v2 - ic2eq > > const output = v0 - v1 > > > > So the DF1 without noise shaping you have 9 ops and you need to add > > noise shaping to get reasonable performance and with the svf you have > > 12 ops and already very good performance. And there is one more > > important thing to note, if you bell gain is 0 dB then the a0 term in > > the SVF trap will be 0, so all the terms are 0 including v1, so then > > you have at the end v0 - 0 = v0 so you get your input back bit for > > bit. > > > > But... we aren't ev
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Andy makes a good point—DF1 is indeed pretty poor, extremely sensitive to quantization error at the low end. With 24-bit fixed point, 56-bit accumulation of the moto/freescale family, which I know Robert is extremely familiar with, and a natural for implementing DF1, it's still not good enough for audio without error shaping. I've done both first and second order, and first order was certainly adequate for what I ever needed, a huge improvement for very little cost. But as Andy said, that doesn't mean that DF1 performance is not poor numerically, at the low end anyway. (But for floating point I'd use transposed DF2.) For anyone interested, here's the block diagram: http://www.earlevel.com/DigitalAudio/images/BiquadDFIN.gif (from this article: http://www.earlevel.com/main/2003/02/28/biquads/ ). "Q", the quantized output, is simply the output of the accumulator (the central "+") at reduced resolution (in 56k, the accumulator is 56 bits, but the unit delays are 24-bit, and we're doing 24x24 MACs anyway). So the difference between the accumulator and the quantized output is the error, the amount that was lost in the quantization step, and that gets fed back via the delay. On Nov 11, 2013, at 6:29 PM, Andrew Simper wrote: > On 11 November 2013 08:09, robert bristow-johnson > wrote: >> On 11/8/13 6:47 PM, Andrew Simper wrote: >>> >>> On 9 November 2013 08:57, Tom Duffy wrote: Having worked with Direct-Form I filters for half of my career, I've been glossing over this discussion as not relevant to me. >>> >>> It depends if you value numerical performance, cutoff accuracy, dc >>> performance etc etc, DF1 scores badly on all these fronts, >> >> >> nope. > > Actually yep. Whenever I mentioned DF1 I meant DF1, not DF1 with added > and noise shaping. I'm using the algorithms you published in your RBJ > audio eq cookbook, I could see no mention of noise shaping there, nor > using a mapping from cos to sin to help out in the text that you > wrote, not even as a one line disclaimer saying: "oh and watch out for > using this, if you don't use double precision you will most likely > need noise shaping to get reasonable audio performance". > > >>> and this is even in the case where you keep your cutoff and q unchanged. >>> >> >> you can, for a lot fewer instructions than a lattice or a ladder or an SVF, >> do a DF1 with noise shaping with a zero in the quantization noise TF at z=1 >> that obliterates any DC error. infinite S/N at f=0. in a fixed-point >> context, this DF1 with noise shaping (sometimes called "fraction saving), >> has *one* quantization point, not two, not three. > > I don't believe you, so how about post some code so show it? Actually > I do believe you but I'm too lazy and completely un-motivated to work > through and double check a correct implementation of DF1 with noise > shaping, but I would love to add the results of this to all the plots > I've done so people can make a more informed decision when comparing > the different methods. > > Now lets have a look at a bell using DF1 or SVF trap: > > DF1 bell (5* 4+ 4=) > const x0 = input > const y0 = b0*x0 + b1*x1 + b2*x2 + a1*y1 + a2*y2 > x2 = x1 > x1 = x0 > y2 = y1 > y1 = y0 > const output = y0 > > SVF Trap bell (6* 6+ 2=) > const v0 = input > const v1 = a0*v0 + a1*ic1eq + a2*ic2eq > const v2 = ic2eq + g*v1 > ic1eq = 2*v1 - ic1eq > ic2eq = 2*v2 - ic2eq > const output = v0 - v1 > > So the DF1 without noise shaping you have 9 ops and you need to add > noise shaping to get reasonable performance and with the svf you have > 12 ops and already very good performance. And there is one more > important thing to note, if you bell gain is 0 dB then the a0 term in > the SVF trap will be 0, so all the terms are 0 including v1, so then > you have at the end v0 - 0 = v0 so you get your input back bit for > bit. > > But... we aren't even considering time varying behaviour here. > > >> you can also rewrite equations to get rid of the "cosine problem", which is >> at the root of problems regarding "cutoff accuracy". you do it by >> replacing, in your equations, every occurrence of cos() with this: >> >> >> cos(2*pi*f0/Fs) <-- 1 - 2*( sin(pi*f0/Fs) )^2 >> >> as you can see, even if you have floating point, all of the information >> concerning f0 is in the difference that cos() is from 1. so, assuming >> f0<> f0 is in the mantissa bits that are falling offa the edge as f0 gets lower >> and lower. double precision floats *do* help out here, but it's a numerical >> problem. and all of the designs using tan(pi*f0/Fs) have their own >> numerical problems regarding ranging, which is why i would suggest to move >> away from using tan() as soon as possible in your coefficient math. > > Thanks for pointing this out, I've not explicitly mentioned this > before so its great you've brought it up. This is a part of keeping > coefficients "bounded" and tan is definitely not bounded as your > cutoff approaches
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11 November 2013 08:09, robert bristow-johnson wrote: > On 11/8/13 6:47 PM, Andrew Simper wrote: >> >> On 9 November 2013 08:57, Tom Duffy wrote: >>> >>> Having worked with Direct-Form I filters for half of my >>> career, I've been glossing over this discussion as >>> not relevant to me. >> >> It depends if you value numerical performance, cutoff accuracy, dc >> performance etc etc, DF1 scores badly on all these fronts, > > > nope. Actually yep. Whenever I mentioned DF1 I meant DF1, not DF1 with added and noise shaping. I'm using the algorithms you published in your RBJ audio eq cookbook, I could see no mention of noise shaping there, nor using a mapping from cos to sin to help out in the text that you wrote, not even as a one line disclaimer saying: "oh and watch out for using this, if you don't use double precision you will most likely need noise shaping to get reasonable audio performance". >> and this is even in the case where you keep your cutoff and q unchanged. >> > > you can, for a lot fewer instructions than a lattice or a ladder or an SVF, > do a DF1 with noise shaping with a zero in the quantization noise TF at z=1 > that obliterates any DC error. infinite S/N at f=0. in a fixed-point > context, this DF1 with noise shaping (sometimes called "fraction saving), > has *one* quantization point, not two, not three. I don't believe you, so how about post some code so show it? Actually I do believe you but I'm too lazy and completely un-motivated to work through and double check a correct implementation of DF1 with noise shaping, but I would love to add the results of this to all the plots I've done so people can make a more informed decision when comparing the different methods. Now lets have a look at a bell using DF1 or SVF trap: DF1 bell (5* 4+ 4=) const x0 = input const y0 = b0*x0 + b1*x1 + b2*x2 + a1*y1 + a2*y2 x2 = x1 x1 = x0 y2 = y1 y1 = y0 const output = y0 SVF Trap bell (6* 6+ 2=) const v0 = input const v1 = a0*v0 + a1*ic1eq + a2*ic2eq const v2 = ic2eq + g*v1 ic1eq = 2*v1 - ic1eq ic2eq = 2*v2 - ic2eq const output = v0 - v1 So the DF1 without noise shaping you have 9 ops and you need to add noise shaping to get reasonable performance and with the svf you have 12 ops and already very good performance. And there is one more important thing to note, if you bell gain is 0 dB then the a0 term in the SVF trap will be 0, so all the terms are 0 including v1, so then you have at the end v0 - 0 = v0 so you get your input back bit for bit. But... we aren't even considering time varying behaviour here. > you can also rewrite equations to get rid of the "cosine problem", which is > at the root of problems regarding "cutoff accuracy". you do it by > replacing, in your equations, every occurrence of cos() with this: > > > cos(2*pi*f0/Fs) <-- 1 - 2*( sin(pi*f0/Fs) )^2 > > as you can see, even if you have floating point, all of the information > concerning f0 is in the difference that cos() is from 1. so, assuming > f0< f0 is in the mantissa bits that are falling offa the edge as f0 gets lower > and lower. double precision floats *do* help out here, but it's a numerical > problem. and all of the designs using tan(pi*f0/Fs) have their own > numerical problems regarding ranging, which is why i would suggest to move > away from using tan() as soon as possible in your coefficient math. Thanks for pointing this out, I've not explicitly mentioned this before so its great you've brought it up. This is a part of keeping coefficients "bounded" and tan is definitely not bounded as your cutoff approaches nyquist. It is very easy to work around this by substituting sin/cos and multiplying through so yes there are changes here that can help a particular implementation eg: 1/(1+g(g+k)) = 1/(1+tan(pi wc) (tan (pi wc) + k)) = cos(pi wc)^2 / (1 + k sin (2 pi wc) /2) in which all terms remain bounded all the time. Showing the coefficients as sin and cos terms doesn't really help the clarity of the situation, and deriving the sin and cos version is basic algebra, so I've chosen to leave things as tan - I'll add a note to remind people they can use a sin and cos version if they prefer. I've found for audio rate modulation you can be better off keeping things as tan since then if you use an approximation of tan that contains an error then this error will only be in what the cutoff actually is, but you are modulating the cutoff so an exact result isn't required. If you use a sine and cosine approximation then the maths falls down and the coefficients you generate may not be stable (or have the exact cutoff). Once the filter is static again you can use a precise version and get an exact cutoff. > you'll get something a little different, but pretty strongly related to the > standard DF1. > Thanks Robert for your continued input on this topic, it's great to have such an expert on DF1 stuff to discuss things with and bring up important points. All the best, Andy -- dupswapdrop -- the music-dsp ma
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11-Nov-13 17:33, Dave Gamble wrote: At some point, the process of using algebraic rearrangements [...] got dubbed the "delay-free" or "zero delay filters" movement. Hi Dave I think this is exactly the source of the confusion. As the distinctive feature of those filters were zero-delay feedback loops, the filters were called "delay-free feedback filters" or "zero delay feedback filters" (which was further shortened to "zdf filters" or "0df filters"). Then someone thought that "0df" stands for "zero-delay filter" rather than "zero-delay feedback" and there you are :D Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On Monday, November 11, 2013, Urs Heckmann wrote: > > > On 11.11.2013, at 01:33, robert bristow-johnson > wrote: > > > > but you cannot define your current output sample in terms of the current > > output sample. > > > But that, with all due respect, is what has been done for quite a while. It > isn't the major ingredient of great sound, but it arguably has its perks, > albeit cpu smoking ones. > Sorry to jump in again, but I believe I can rephrase RBJs statement as "computation of the output will always require state" without loss of generality. When I first started reading up on this field, it was implied that a "zero delay filter" was a stateless y=f(x) type affair. That implication is obviously false, but somehow I was mislead into that understanding. If you hold that position and reinterpret RBJs assertion above, you can see its original sense. I've had customers ask me "do your EQs use delays?". The answer is simply "yes, I use the correct delays for my implementation". But somewhere the idea of a stateless EQ has come into existence. iceq1 and iceq2 are exactly state variables. They just happen to be excellent topology-preserving choices of state variable. The correct question from customers should have been "do your EQs add delays that could be avoided by thinking more carefully?". Best, Dave -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On Monday, November 11, 2013, robert bristow-johnson wrote: > > >> So "delay-free" is a pointless expression to me, > > > it has been used to discuss or advertise delay-free feedback which, to me, > still remains an impossibility for discrete-time systems. > > > and i've seen the papers. when it all boils down to it in a real-time > filter, you are defining your current output sample in terms of the current > input sample and previous input samples and, if it's recursive, the previous > output samples. but you cannot define your current output sample in terms of > the current output sample. > Sorry to interject, but I believe I can clarify this. Obviously you're correct in your assertion (RBJ), but the phrase "delay-free" is something akin to a marketing term that was being bandied about a year or so ago. Evidently it has not been clearly explained if you're none the wiser to this. It stems from this, and its ilk: http://musicdsp.org/showArchiveComment.php?ArchiveID=24 which is an implementation of Stilson and Smiths (now classic?) analysis of the Moog diode-ladder VCF. As you can verify by inspection, a single-sample delay has been added in to the implementation to approximate the feedback path. It is *this* entirely spurious delay that is being used in the phrase "delay-free". Above is the entire point. I'm now going to provide what I believe to be the history of usage of the phrase, which I don't expect to be very interesting to anyone besides myself, I'm just noting it down here. What appears to have happened is that the musicdsp.org sample code came into common usage for synth filters. If you quickly check the maths, you'll see that the xfer function of the filter is rather destroyed by this "tweak for computability". I am aware of this "trick" (insert a sample delay into a feedback path) being used in quite a few places where the alternative proved too costly to compute. By my reckoning, it died out a few years ago, though I suspect it's still around somewhere. While my memory is absolutely not to be trusted, I think I remember chatting with Andy about this, and I'm sure I have this wrong, but at the time, he wasn't convinced that things such as the RBJ filters were technically "delay free". I think I made the argument that if someone were to go about inserting arbitrary unit delays into circuit models, the magnitude responses would be so far off as to be worthless. In any case, I'm extremely pleased to see Andy clearly state the case as above. At some point, the process of using algebraic rearrangements such as Andy and Vadim (as progenitor of this phase. The previous phase obvious to me being Serafini, but I'm only speaking off the top of my head; this is a wonderfully rich topic with lots of great results) present, in order to allow numerical solvers to give efficient simulation of nonlinear phenomena in filter stages - which offers extremely audible improvements (since the xfer function is not being hacked at!) got dubbed the "delay-free" or "zero delay filters" movement. It was a buzz-word amongst consumers for a while, and to some extent still is. As a designer of completely linear EQs, I had to spend a fair bit of time explaining that ALL linear EQs are "delay free" in the sense that the phrase is meant; I believe it's just an unfortunate choice of phrasing, because it appears to mislead at all levels. (Excepting the immensely specific one I described) Nonetheless, people on this list (most obviously Andy) are providing wonderful contributions which I'm certain will drive forward the quality of implementations. I'd like to claim that the approximation used in that Stilson and Smith code has become something of an albatross, and we're well shot of it. Conversely, I'm unable to separate "trapezoidal integration" from bilinear transform in my head. That's two names for the same thing. Perhaps I'm too glib with the maths, and I'll absolutely accept such criticism, but for me one of the great joys of linear system theory is that all the different techniques are exactly the same maths with different formalisms, some of which make the working simpler for certain problems. I think Moorer wrote an article wittily titled The Manifold Joys Of Conformal Mapping, which, whilst perhaps most interesting to the harmonic analysts amongst us, reinforces this very deep truth. Please take that as an observation, not a criticism. It's absolutely not my place to critique anyone's style of teaching! I daren't even dream I could do as good a job as you're already doing. I'd like to offer some response to Theo Verelst's postings, since I think he's raising some interesting points, but I'm extremely sorry to say that I don't feel sufficiently confident that I understand his position to engage. Again, my apologies. Warmest regards, Dave. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11-Nov-13 13:04, Theo Verelst wrote: Alright, simply put: the paradigm used to work with digital filters is at stake Funnily enough, it's a mathematically trivial fact that in the LTI case the 0df filters are mathematically equivalent to the DF BLT filters. So, the only "non-scientific" part there is about estimating the errors of time-varying and nonlinear effects. But then, I'm not so much aware (please correct me, if I'm wrong), if there are any psychoacoustically usable measurables developed until now, which help with those estimations. OTOH, the psychoacoustically perceivable error of the linear model is clearly estimatable by using the frequency response paradigm, but as I just said, in this respect 0df is fully equivalent to the DF BLT. So, it seems to me that it's not the paradigm, which is being put at stake, but rather only the methodology of digital filter design. Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Urs Heckmann wrote: ... Hehehe, I'm sorry, but this sounds an aweful lot more like a cleric's point of view than a scientist's one ;-) While I agree that "zero delay feedback filters" have been advertised to death (mea culpa), I don't think it's wise to use that as a proof of their non-existance. . Alright, simply put: the paradigm used to work with digital filters is at stake, so of course I've not been telling people to do or not to do certain things, and of course it is a beautiful thing if your software synthesizer makes good music, in principle that doesn't depend on the name of the mathematics you use, or the congruence you appear to perceive between a certain circuit simulation and analog circuits (or how good the match between the signal at the output of your sound card and an analog filter based synthesizer is). But, theoretically it doesn't matter at the foundation level if you replace a (theoretically infinite) sum of sinc integrals with a 0th, 1st or a second order functional approximation, and subsequently perform equal length numerical integration iterations, or if you want to make, on the basis of this, a signal estimate and presume that now the circuit loop for creating resonance effects functions better: because the theoretical congruence has already been lost to a fair degree. not that the results cannot, or should not be used, but the mathematical "strength" of using a complex function theory approach-equivelent in the sample (z) domain simply isn't even near as good, so a lot of "fixing holes" is necessary, which isn't the case for the continuous time domain mathematics, which are really important in the foundations of EE. and have played a big role in EE designs throughout history, and in other sciences. Talking about filters, phases, feedback delays, etc, is terminology that doesn't come from iteration math. So, maybe there are cases for which the approach gives perfectly usable and accurate enough results, but don't feel taken by thesuggestion of those mathematical techniques, and in principle think about it that the whole digital filter and oscillator "circuitry" from cookbooks may in the end benefit from different tunings than you anticipate, because it isn't easy to oversee the short and long digital signal effects all these things have. But loosing grip at the fundamental level isn't a very good starting point to believe you'll span a "new science", that is clear from really not "research" level EE stuff, even though that's tempting. Oh, and for the non-linear circuit simulation people, it isn't so that the well known circuit simulators (Spice being from the 60s onward the most well known) are simple state-space progression iteration engines, just like splitting up the state-evolver matrix operator isn't necessarily meant to act in the sampled domain, usually the integration connected with s-transform network elements (like resistors and capacitors) is preceded by a DC-analyis (any iteration which can be proven to converge will do), and often the *time step isn't constant*, i.e. the circuit behavior integrator will chose which time step is sufficient, and can also decide on which integration methods to use. So in principle you can use an iterative method to imitate the time-behavior a non-linear filter electronic circuit, but you may have to oversample quite a bit, which requires the use of more vertical resolution (more bits in you state space samples), and, apart form more advanced frequency methods, matching the integral with the circuit may be a good idea. And this whole process would best be iterative, and with some measure or even areliable upper bound of error, so guided reiterations are possible. T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11.11.2013, at 02:21, robert bristow-johnson wrote: > On 11/10/13 5:12 PM, Urs Heckmann wrote: >> On 11.11.2013, at 01:33, robert bristow-johnson >> wrote: >> >>> but you cannot define your current output sample in terms of the current >>> output sample. >> But that, with all due respect, is what has been done for quite a while. > > it's been reported or *reputed* to be done for quite a while. > > but when the smoke and dust clear, logic still prevails. Hehehe, I'm sorry, but this sounds an aweful lot more like a cleric's point of view than a scientist's one ;-) While I agree that "zero delay feedback filters" have been advertised to death (mea culpa), I don't think it's wise to use that as a proof of their non-existance. Unlike pixiedust, there's a lot of working source code out there. Thus the scientific way to prove a "heretic" like myself wrong is by falsifying those. The easiest way of which would be pointing out a bug, or simply showing by measurements that those filters perform worse for their purpose than, say, the ones you so famously taught us (for which I'm eternally grateful). - Urs -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11-Nov-13 01:09, robert bristow-johnson wrote: On 11/8/13 6:47 PM, Andrew Simper wrote: It depends if you value numerical performance, cutoff accuracy, dc performance etc etc, DF1 scores badly on all these fronts, nope. and this is even in the case where you keep your cutoff and q unchanged. Hi Robert, from your reply I understood that you're referring to the parameter quantization, while I think Andy was referring to the state quantization. Furthermore, also parameter quantization seems much less of an issue with the 0df approach, since cos(...) doesn't occur there (although I don't have a rigorous proof). Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11/8/13 11:50 PM, David Reaves wrote: I think the distinction is that "SCIENCE" is open-minded. "Scientists," OTOH, are only open-minded if they choose to be. But then, the closed-minded ones aren't really scientists, now are they? ;-) oh, c'mon. *anyone* can be close-minded. being skilled in science or any other discipline is no immunity for close-mindedness. e.g. Richard Dawkins. -- r b-j r...@audioimagination.com "Imagination is more important than knowledge." -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11/8/13 6:47 PM, Andrew Simper wrote: On 9 November 2013 08:57, Tom Duffy wrote: Having worked with Direct-Form I filters for half of my career, I've been glossing over this discussion as not relevant to me. It depends if you value numerical performance, cutoff accuracy, dc performance etc etc, DF1 scores badly on all these fronts, nope. and this is even in the case where you keep your cutoff and q unchanged. you can, for a lot fewer instructions than a lattice or a ladder or an SVF, do a DF1 with noise shaping with a zero in the quantization noise TF at z=1 that obliterates any DC error. infinite S/N at f=0. in a fixed-point context, this DF1 with noise shaping (sometimes called "fraction saving), has *one* quantization point, not two, not three. you can also rewrite equations to get rid of the "cosine problem", which is at the root of problems regarding "cutoff accuracy". you do it by replacing, in your equations, every occurrence of cos() with this: cos(2*pi*f0/Fs) <-- 1 - 2*( sin(pi*f0/Fs) )^2 as you can see, even if you have floating point, all of the information concerning f0 is in the difference that cos() is from 1. so, assuming f0
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
as a longtime lurker, it's really nice to see this list heating up again, and to see mr. simper's comments finally make it through. cytomic is wonderful stuff and i for one certainly appreciate the sharing. there's a non-technical thread of discussion interleaved here, which is about education and theoretical accuracy and so on. it's wearisome and frequently insulting. creative technology has never advanced solely by cleaving to strict numerical perfection, and will not do so in the future. there are other fora for talking about DSP applications in automotive or medical technology or other truly critical problem domains. [or even AD/DA design, loudness limiting, other low-level and certainly important problems.] but in music, we can afford to play around and follow the ears anyways, please post more, everyone! mr heckmann, your synth is lovely and i look forward to hearing any advice you have or things you've learned, and i'd love to read that paper. thanks again, and all the best ezra buchla On Sun, Nov 10, 2013 at 10:48 AM, Urs Heckmann wrote: > Hi Douglas, > > No worries, I couldn't have started my business without this list, it was an > important factor in my career - for the very reason that it isn't strictly > academic. I would love to give back if it's of anybody's help. > > (if we ever find the time to write that damn paper ;-) > > Thanks, > > - Urs > > On 10.11.2013, at 16:03, douglas repetto wrote: > >> >> Urs, I don't know if you're referring to music-dsp here, but this list is >> specifically not meant to be in the academic realm, but rather a place where >> people of all sorts with an interest in music and digital signal processing >> can chat. So I encourage you to share your results here! >> >> I'm sorry there has been unpleasantness on the list recently. >> >> best, >> douglas >> >> >> >> On 11/10/13 10:00 AM, Urs Heckmann wrote: >>> We had planned to write a paper about our numerical method for the >>> non-linear case, including a pretty fast solving algorithm that's >>> fundamentally more precise than Newton-Raphson. But seeing how this >>> won't be well received in the academic realm (seemingly too trivial), >>> we might just share it in more practically oriented place (KVR dev >>> forum). >> >> -- >> ... http://artbots.org >> .douglas.irving http://dorkbot.org >> .. http://music.columbia.edu/cmc/music-dsp >> ...repetto. http://music.columbia.edu/organism >> ... http://music.columbia.edu/~douglas >> >> >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, dsp >> links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Hi Douglas, No worries, I couldn't have started my business without this list, it was an important factor in my career - for the very reason that it isn't strictly academic. I would love to give back if it's of anybody's help. (if we ever find the time to write that damn paper ;-) Thanks, - Urs On 10.11.2013, at 16:03, douglas repetto wrote: > > Urs, I don't know if you're referring to music-dsp here, but this list is > specifically not meant to be in the academic realm, but rather a place where > people of all sorts with an interest in music and digital signal processing > can chat. So I encourage you to share your results here! > > I'm sorry there has been unpleasantness on the list recently. > > best, > douglas > > > > On 11/10/13 10:00 AM, Urs Heckmann wrote: >> We had planned to write a paper about our numerical method for the >> non-linear case, including a pretty fast solving algorithm that's >> fundamentally more precise than Newton-Raphson. But seeing how this >> won't be well received in the academic realm (seemingly too trivial), >> we might just share it in more practically oriented place (KVR dev >> forum). > > -- > ... http://artbots.org > .douglas.irving http://dorkbot.org > .. http://music.columbia.edu/cmc/music-dsp > ...repetto. http://music.columbia.edu/organism > ... http://music.columbia.edu/~douglas > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 09.11.2013, at 01:57, Tom Duffy wrote: > To paraphrase, all are good enough if the frequency > is low (< pi/3); Simpsons is the best, but blows > up above 0.8 pi Note that Andys approach uses trapezoidal integrators just as that - integrators. While the whole structure of the SVF looks like a 2nd order biquad, it isn't one. The z-1 sections are all in branches parallel to the signal path. The "blow up" problem of classical digital implementations of SVFs (e.g. Chamberlin) stems from the unit delay in the feedback path. This unit delay isn't present in Andy's approach and thus there is no "blow up" problem anywhere below Nyquist. The obvious advantage of Andy's approach is the numerical accurateness. Unlike biquads which require double precision floating processing from 2nd order and up, Andys filters don't suffer much from rounding errors. This should be obvious because the "biquad filter coefficients" (if you really want to call them that - I really prefer Andy's term) of the integrators are 1.0f The thing about the recent approaches to eleminate the unit delay in the feedback path is the vastly improved stability, the much closer match of phase response towards analogue equivalents and the true independence of cutoff and resonance that make these filters sweepable. The drawback of these approaches is the higher computational effort, which has become less of an issue for realtime processing on desktop computers in recent years. - Urs -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
I think the distinction is that "SCIENCE" is open-minded. "Scientists," OTOH, are only open-minded if they choose to be. But then, the closed-minded ones aren't really scientists, now are they? ;-) David Reaves Recklinghausen, Germany On Fri, 08 Nov 2013 22:34:51 +, David Hoskins wrote: > > > As with all disciplines, when someone doesn't speak the 'correct' > technical language they are shunned, mainly because the academics have > invested all that time and money into said work, an automatic defensive > stance clicks in. > As an aside, in Universities people can be shut out for decades simply > for disagreeing with the current paradigms, taking years to prove > themselves correct all along - so much for scientists being open minded. > > Dave. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 9 November 2013 08:57, Tom Duffy wrote: > Having worked with Direct-Form I filters for half of my > career, I've been glossing over this discussion as > not relevant to me. It depends if you value numerical performance, cutoff accuracy, dc performance etc etc, DF1 scores badly on all these fronts, and this is even in the case where you keep your cutoff and q unchanged. > I went back and re-read it, and if you can get past > the scribbled diagrams and a few hand-waving / bypassed > steps, I can appreciate that Andrew has derived a > useful digital model of an analog circuit that is often > used in synthesizers (The state variable filter). I find it much quicker and easier to hand draw a diagram and take a photo than using vector drawing packages or tools like tikz or circuitz (although the latter two do make nice diagrams). If I give a presentation I would also rather use a white board or draw on overhead slides by hand than use powerpoint or similar tools. > What Theo has also noted is that Andrew has in > the process come up with some new naming conventions > that confuse, conflate or otherwise seem contrary to > academic use. This makes it difficult to see how > the derivation differs from, or is identical to, > classical approaches. I haven't come up with any new naming conventions, nor any acronyms to describe things (I haven't really come up with much actually), I'm using the naming conventions of the technical papers of qucs (which are also used widely in the elsewhere) which I have provided links to as part of the references. If you are not familiar with these naming conventions then that's fine, but please don't think I came up with new naming conventions just to "confuse" people, the good thing about conventions is that there are so many of them! I used the letter "g" for conductance (http://en.wikipedia.org/wiki/Electrical_conductance) which is standard, and then the closest letter to "g" that isn't used for anything else much "k" for the gain of the resonance path (which is voltage gain in this case), which are clearly marked (ok scribbled!) in the diagram, these don't really matter much and don't change any of the working. I also use "v" for voltages, and "i" for currents, the letter "c" for capacitors they all seem pretty standard to me. Then there is "eq" for equivalent, and n and n+1 for nth and n+1 st time steps (all from the qucs link), and finally "wc" for the cutoff frequency (ok so this perhaps should be w0 but I don't want to confuse it with gain coefficients or voltages). All the best, Andy -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Having worked with Direct-Form I filters for half of my career, I've been glossing over this discussion as not relevant to me. I went back and re-read it, and if you can get past the scribbled diagrams and a few hand-waving / bypassed steps, I can appreciate that Andrew has derived a useful digital model of an analog circuit that is often used in synthesizers (The state variable filter). What Theo has also noted is that Andrew has in the process come up with some new naming conventions that confuse, conflate or otherwise seem contrary to academic use. This makes it difficult to see how the derivation differs from, or is identical to, classical approaches. I went to my shelf and picked up "Designing Digital Filters", Charles S. Williams, 1986 This was the textbook for my Undergrad EE course in DSP. Section 2.5 is specifically on approximations to integrators, and gives a very clear (to me, now, 20 some years later) explanation of the advantages and disadvantages to the variations: Running Sum (Euler), Trapezoidal, and Simpsons. To paraphrase, all are good enough if the frequency is low (< pi/3); Simpsons is the best, but blows up above 0.8 pi Anyway, I hope this sums up the thread for anyone trying to decipher it in the future. Tom. NOTICE: This electronic mail message and its contents, including any attachments hereto (collectively, "this e-mail"), is hereby designated as "confidential and proprietary." This e-mail may be viewed and used only by the person to whom it has been sent and his/her employer solely for the express purpose for which it has been disclosed and only in accordance with any confidentiality or non-disclosure (or similar) agreement between TEAC Corporation or its affiliates and said employer, and may not be disclosed to any other person or entity. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Richard Dobson wrote: The issue is not the imparting of knowledge (the more the merrier), it's the attitude towards others; There's also a difference between a great pretender digging up ancient treasure, and Harry Callahan joining NCIS to solve a murder, and assumptions of the kind that "everything is relative". When researching a mummy, you may chose to believe that the biggest D-head archeologist would better be considered right. When Karpov meets Einstein, the rules are different, and I don't ever see any respect coming to that side of the equation, from some people, ever. That's not dumb, that's bad. There, I said it. About DSP: it isn't needed to presume "big bang theories" or find friends to fight that idea, and have all kinds of rationalizations about algorithms to be going on for professional purposes: nobody in the serious pro-EE industry for instance us going to find any use for that, and more than a few are immensely more advanced than that. So it is an insult to always presume this to be not true, just to save some rather hobby-ist type of imagined ego. Of course not as an excuse to put people down or abuse their soul. The more you ask the more you may find out I'm not being unrealistic about warning some not-friends all over the world that the big boat of EE is really terribly, terribly capable of calling all the types of endeavors that I may not call crappy because of your feelings even less then shitty. So I'm saying *IF* and *only if* you are the actual new rocket scientists, you could as it were "command" a certain type respect. But it's my respect for normal, and normal (hobby-) scientific humanity that let's me not give way to the rocket scientist respect, because I know beyond any shadow of doubt I don't err too much at all about this. Euler integration is first year stuff being *taught*, not being researched. And isn't a terribly advanced method when compared to circuit simulation software from the sixties. And that sort of software can solve for hundreds of poles, not 4. So sorrym, I seriously mean it, I can adapt to people hobby skills, acknowledge that it isn't easy to implement a nice network simulation (because it is hard, and you'd stand on many great peoples' shoulders to get it done right), but blatant babble from someone who doesn't know a difference equation from a current integral, and at first even doesn't acknowledge a major, essential sampling theorem from the 60s or so, doesn't strike me as respectful. It just doesn't. That's the danger of dabbling in science AND listen to certain quacksalvers. I'm fine in that respect, I just don't like all TOO much overdone scientific demagogy, that's my main point. Even though that style _could_ be used for good. And as such I can afford the cr*p word, and the dumb word to make a very necessary point, IMO. But not for me, I can download free stuff, I don't buy the non-sense, I've monitored enough to know what's what. But it is still an insult to a lot of people to act so dumb. And to not want to know, so vehemently. But anyway.. T. V. T. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
There are so many different avenues to go in DSP, that I'm sure there are some on here that have spent many years travelling down just one of them. Take psycho-acoustic studies for example, where brain function is the riding force, rather than mathematics. It can be half a lifetime of work and have nothing to do with their academic schooling in the end - their degree seems like a very long time ago now. But it can still be talked about on here, hopefully. As with all disciplines, when someone doesn't speak the 'correct' technical language they are shunned, mainly because the academics have invested all that time and money into said work, an automatic defensive stance clicks in. As an aside, in Universities people can be shut out for decades simply for disagreeing with the current paradigms, taking years to prove themselves correct all along - so much for scientists being open minded. Dave. On 08/11/2013 21:12, Theo Verelst wrote: Richard Dobson wrote: -1. I think everyone on this list is entitled not to be looked down upon, including musicians (this is MUSIC-dsp after all!), who have also had (and must be presumed to have had in the absence of information to the contrary) a rigorous "formal education", and who typically have extended that education considerably further in their own time and their own way, as they have felt the need. There is nothing wrong in anyone being proud of the studies they have undertaken, and of the qualification they have obtained, but they can also do that without feeling the need to express or imply an automatic intellectual or moral superiority over all others. That is the overriding impression I get from Theo – if you don't have an EE degree you know nothing. Don't you feel that if I'm simply right, and refuse to subscribe to the sort of "crime of century", that the insult is really the way I described ? Unless you say I must suffer be higher edified, to give you the privilege to mock about in the digital domain, which is like saying it's ok for your friends to steal all the good info, rewrite history, and you don't want to hear a word about it. Rather an authority to presume. Musically even worse. I've besides having learned myself to be able to play keys (and guitar and if needed drums) at top level, also subscribed to courses and serious learning projects to test my knowledge, and have been in the serious conservatory learning loops to learn more, and refuse to give the centuries old musical knowledge up to subscribe to some stupid tribal dances because some people are too dumb even to make Disco, and have rather dumb (not by education, but humanly speaking) people give credit to thus new times experiments, and give undeserved preference because "it's made by computers" or something. I suppose if you feel insecure about your knowledge, it's natural to oppose the bringer of alleged higher knowledge, unless of course there's no clash of the essence of the "teachers". To simply presume the higher edified is wrong may not be the most optimal discussion technique, though. Also it doesn't instill respect in me. Sorry to say. It actually doesn't. And if my self-respect is based on what I do right, and you're proven mathematically/scientifically wrong, and I've really tried in decent language to call you a dumbass because at the level at hand *you are*, then go figure... T -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
The issue is not the imparting of knowledge (the more the merrier), it's the attitude towards others; the style. If you call people "dumb" all the time (however much you think it is justified), almost as a matter of principle (so anyone who happens to like "tribal dances" is ipso facto "dumb") they will tend to focus on the feeling, rather than on the information. Its a bit like trying to drive with the brakes on. Richard Dobson On 08/11/2013 21:12, Theo Verelst wrote: Richard Dobson wrote: -1. .. Don't you feel that if I'm simply right, and refuse to subscribe to the sort of "crime of century", that the insult is really the way I described ? Unless you say I must suffer be higher edified, to give you the privilege to mock about in the digital domain, which is like saying it's ok for your friends to steal all the good info, rewrite history, and you don't want to hear a word about it. Rather an authority to presume. Musically even worse. I've besides having learned myself to be able to play keys (and guitar and if needed drums) at top level, also subscribed to courses and serious learning projects to test my knowledge, and have been in the serious conservatory learning loops to learn more, and refuse to give the centuries old musical knowledge up to subscribe to some stupid tribal dances because some people are too dumb even to make Disco, -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Richard Dobson wrote: -1. I think everyone on this list is entitled not to be looked down upon, including musicians (this is MUSIC-dsp after all!), who have also had (and must be presumed to have had in the absence of information to the contrary) a rigorous "formal education", and who typically have extended that education considerably further in their own time and their own way, as they have felt the need. There is nothing wrong in anyone being proud of the studies they have undertaken, and of the qualification they have obtained, but they can also do that without feeling the need to express or imply an automatic intellectual or moral superiority over all others. That is the overriding impression I get from Theo – if you don't have an EE degree you know nothing. Don't you feel that if I'm simply right, and refuse to subscribe to the sort of "crime of century", that the insult is really the way I described ? Unless you say I must suffer be higher edified, to give you the privilege to mock about in the digital domain, which is like saying it's ok for your friends to steal all the good info, rewrite history, and you don't want to hear a word about it. Rather an authority to presume. Musically even worse. I've besides having learned myself to be able to play keys (and guitar and if needed drums) at top level, also subscribed to courses and serious learning projects to test my knowledge, and have been in the serious conservatory learning loops to learn more, and refuse to give the centuries old musical knowledge up to subscribe to some stupid tribal dances because some people are too dumb even to make Disco, and have rather dumb (not by education, but humanly speaking) people give credit to thus new times experiments, and give undeserved preference because "it's made by computers" or something. I suppose if you feel insecure about your knowledge, it's natural to oppose the bringer of alleged higher knowledge, unless of course there's no clash of the essence of the "teachers". To simply presume the higher edified is wrong may not be the most optimal discussion technique, though. Also it doesn't instill respect in me. Sorry to say. It actually doesn't. And if my self-respect is based on what I do right, and you're proven mathematically/scientifically wrong, and I've really tried in decent language to call you a dumbass because at the level at hand *you are*, then go figure... T -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
-1. I think everyone on this list is entitled not to be looked down upon, including musicians (this is MUSIC-dsp after all!), who have also had (and must be presumed to have had in the absence of information to the contrary) a rigorous "formal education", and who typically have extended that education considerably further in their own time and their own way, as they have felt the need. There is nothing wrong in anyone being proud of the studies they have undertaken, and of the qualification they have obtained, but they can also do that without feeling the need to express or imply an automatic intellectual or moral superiority over all others. That is the overriding impression I get from Theo – if you don't have an EE degree you know nothing. Call me old-fashioned etc, but if I have a choice (which is in practice all the time on a mailing list), I will pay much more attention to people who are respectful and polite, than to those who are neither. There cannot be anyone on this list, nor anywhere, who knows so much that they have nothing left to learn, after all...and who really wants to be in such a position? Share and appreciate - not a difficult combination! Richard Dobson On 08/11/2013 19:39, Bastian Schnuerle wrote: +1 Am 08.11.2013 um 19:55 schrieb Theo Verelst: Just a short suggestion: the field at hand has been acknowledged to be let's say classic (for the sake of decorum) EE "subjects", which at the time were hard to do, and interesting a integration POV. Of course I agree that even people, for instance without the luck of having been born in 1st world countries, without all too much formal educations should, if necessary with the constitutional help of government funded activities, be able to enjoy digital technology and digital media and musical materials, and ways to create those. I mean I am for the idea that people, also from using the principle of Open Source (which to decent people means something else than ripping literature for dog food for your little bunch of "friends", I'd think) can enjoy digital music synthesis for instance from their computer. ... -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
+1 Am 08.11.2013 um 19:55 schrieb Theo Verelst: Just a short suggestion: the field at hand has been acknowledged to be let's say classic (for the sake of decorum) EE "subjects", which at the time were hard to do, and interesting a integration POV. Of course I agree that even people, for instance without the luck of having been born in 1st world countries, without all too much formal educations should, if necessary with the constitutional help of government funded activities, be able to enjoy digital technology and digital media and musical materials, and ways to create those. I mean I am for the idea that people, also from using the principle of Open Source (which to decent people means something else than ripping literature for dog food for your little bunch of "friends", I'd think) can enjoy digital music synthesis for instance from their computer. My concern, besides the idea that it is all too simple to take some (well chosen) keywords and make yourself popular by using them, is that the academic sport which *did* actually invent these ideas, came to quite different conclusions about the use of these basic DSP ideas than people seem to think. I think without betraying them, it is a good idea that I and other spend some time and attention to make this clear, besides pointing out that integrating step functions based on equidistant samples is really NEVER going to converge to any time- continuous signal worthy of notion, unless you know quite well what you're doing, what you're limitations are, and have some taste in musical instruments and monitoring them. So, at the risk of simply proving that some people are serious of wanting the crime of betraying the good and replace and sell it by making bad products, as long as they can happy-ho among eachother and look interesting for certain "new" movements of people, here's a serious consideration. When making use of the digital synthesis results, it can be proven that the typical approximation will give certain predictable sorts of distortion (you could take my word for it, I'm not new to this subject, and think I have learned something at university), that in the first place you can find hard to escape from. But, more importantly, and more to the point than trading off what these types of (clearly present, I mean seriously, do you guys listen to your own works sometimes?) distortion, there are certain, granted: pro-level, considerations about creating waves in reverberant spaces, and waves in Disco-like situations, which prevent peoples hearing from getting damaged, and from people abusing sound for such purposes. Of course this is not necessarily connected with DSP as a hobby or innocent profession, but I have the feeling some people might be deluded into believing that a system "without feedback delay" or with some fancy-name "prediction integral" can defeat the loudness control in Public Address systems made in my engineering domain, when the next "rave controller" wants to abuse yet another crowd and prove his/her loudness superiority. Some people fall for that crap, seriously, and that I find not good. T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Just a short suggestion: the field at hand has been acknowledged to be let's say classic (for the sake of decorum) EE "subjects", which at the time were hard to do, and interesting a integration POV. Of course I agree that even people, for instance without the luck of having been born in 1st world countries, without all too much formal educations should, if necessary with the constitutional help of government funded activities, be able to enjoy digital technology and digital media and musical materials, and ways to create those. I mean I am for the idea that people, also from using the principle of Open Source (which to decent people means something else than ripping literature for dog food for your little bunch of "friends", I'd think) can enjoy digital music synthesis for instance from their computer. My concern, besides the idea that it is all too simple to take some (well chosen) keywords and make yourself popular by using them, is that the academic sport which *did* actually invent these ideas, came to quite different conclusions about the use of these basic DSP ideas than people seem to think. I think without betraying them, it is a good idea that I and other spend some time and attention to make this clear, besides pointing out that integrating step functions based on equidistant samples is really NEVER going to converge to any time-continuous signal worthy of notion, unless you know quite well what you're doing, what you're limitations are, and have some taste in musical instruments and monitoring them. So, at the risk of simply proving that some people are serious of wanting the crime of betraying the good and replace and sell it by making bad products, as long as they can happy-ho among eachother and look interesting for certain "new" movements of people, here's a serious consideration. When making use of the digital synthesis results, it can be proven that the typical approximation will give certain predictable sorts of distortion (you could take my word for it, I'm not new to this subject, and think I have learned something at university), that in the first place you can find hard to escape from. But, more importantly, and more to the point than trading off what these types of (clearly present, I mean seriously, do you guys listen to your own works sometimes?) distortion, there are certain, granted: pro-level, considerations about creating waves in reverberant spaces, and waves in Disco-like situations, which prevent peoples hearing from getting damaged, and from people abusing sound for such purposes. Of course this is not necessarily connected with DSP as a hobby or innocent profession, but I have the feeling some people might be deluded into believing that a system "without feedback delay" or with some fancy-name "prediction integral" can defeat the loudness control in Public Address systems made in my engineering domain, when the next "rave controller" wants to abuse yet another crowd and prove his/her loudness superiority. Some people fall for that crap, seriously, and that I find not good. T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 08-Nov-13 12:13, Urs Heckmann wrote: No offense meant, I wasn't aware that your book was considered a standard dsp lecture. If you know of any university that uses it in their curriculum, please let me know and I'll recommend that university. Damn, you got me there ;-) -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 08.11.2013, at 10:21, Vadim Zavalishin wrote: >> > > Hi Urs! I don't believe this. So, you think that "The art of VA filter > design" book doesn't cover it? > > Regards, > Vadim Hi Vadim, No offense meant, I wasn't aware that your book was considered a standard dsp lecture. If you know of any university that uses it in their curriculum, please let me know and I'll recommend that university. - Urs -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 08-Nov-13 10:34, STEFFAN DIEDRICHSEN wrote: If you look at Figure 3.18 of said book, there’s a delay in the feedback path. But it’s done in an elegant way, so no insult here. ;-) Damn, I probably should remove the said Figure (and Figs. 3.19-3.20 for that matter) in the next revision. Thanks for the proofreading! ;-) ;-) ;-) Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
If you look at Figure 3.18 of said book, there’s a delay in the feedback path. But it’s done in an elegant way, so no insult here. ;-) Steffan On 08.11.2013, at 10:21, Vadim Zavalishin wrote: > Hi Urs! I don't believe this. So, you think that "The art of VA filter > design" book doesn't cover it? -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 08-Nov-13 03:13, Ross Bencina wrote: Now, I do have one thing I would like to see: and that is a mathematical proof that point (4) above is actually true for this topology. Ever since I read the Laroche BIBO paper it scared the crap out of me to be modulating any IIR filter at audio rate without a trusted analysis. Hi Ross, I once tried to do the analysis you mentioned. IIRC, I managed to successfully show the time-varying BIBO stability of analog 1-pole (this is very simple) and 2-pole (somewhat more tricky) analog SVFs under the condition that the real parts of all poles are "uniformly negative" (that is bound by some negative constant from above). IIRC, it is also quite straightforward to show the time-varying stability of a 2nd-order real Jordan cell (which probably has the best time-varying stability anyway), but this one is not so convenient as the LP/BP/HP multimode SVF. I have no idea if there are papers addressing this. For the discrete-time versions it seemed way more complicated. I couldn't prove it or build a disproving example for the TPT BLT version of the same 2-pole SVF (and I don't remember whether I managed to build a proof for the 1-pole). Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 08-Nov-13 10:00, Urs Heckmann wrote: I have however not followed this list in a while, so my apologies if "0df" has been discussed in a wider scope than Andy's papers before - I have yet to see a standard dsp book that covers it. However, products on the market seem sparse thus I think it may not have...? Hi Urs! I don't believe this. So, you think that "The art of VA filter design" book doesn't cover it? Regards, Vadim -- Vadim Zavalishin Reaktor Application Architect Native Instruments GmbH +49-30-611035-0 www.native-instruments.com -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Thanks Andy, I've just subscribed to the list again to thank you for the updated models. I've also subscribed to express my puzzledness about the negative responses. Like in other forums, a few dsp nerds don't seem to "get" the elimination of the unit delay in feedback-based algorithms that dsp literature is so soaked in. Maybe they don't see the woods for the trees? The status quo of digital models of analogue filters has left unit delays behind, even for heavily non-linear models. Andy's method has proven helpful for us in deriving non-linear models of analogue filters from their "ideal" linear circuit equivalents. Thus for me any criticism I've seen was premature and did not take into account that Andy's method is a brilliant initial step in this process, while standard dsp literature with their abstract non-topology-preserving methods is, quite frankly, not. I have however not followed this list in a while, so my apologies if "0df" has been discussed in a wider scope than Andy's papers before - I have yet to see a standard dsp book that covers it. However, products on the market seem sparse thus I think it may not have...? Regards, - Urs -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Hi Theo, It sounds like you are upset with me not addressing the original list of points you made, so let me do that for you now. On 6 November 2013 22:13, Theo Verelst wrote: > > Andrew Simper wrote: >> >> Here is an updated version of the optimised trapezoidal integrated svf >> which bundles up all previous state into equivalent currents for the >> capacitors, which is how I solve non-linear circuits (although this >> solution is just the linear one that I'm posting here). The only thing >> to note that with trapezoidal integration you have gain terms of g = >> tan(pi*cutoff/samplerate) which become very large with high cutoff, so >> care needs to be taken if these "g" terms stand alone since the >> scaling can get large and could impact numerical performance: >> >> > > That's a lot of approximations and (to me !) unclear definitions on a row. > Granted I like it when Network Theory (the EE kind) from the 50s and 60s and > approximation methods from the 70s and 80s (for supercomputers) are put to > good use, but I hope you are aware of the following theoretical limitations: Can you please provide me a list of the approximations you think I've made that you are not happy with? Apart from applying numerical integration the rest of the algorithm makes no approximations and is derived from Nodal Analysis on idealized components and linear algebra, so there are no approximations. Are you talking about the general limitations of processing on a finite number of points? This is the music-dsp email list if you weren't aware, so those same limitations apply to every single thing people talk about here! > - sampling theory states you can work in the z domain, taking z^-1 as a > delay that can be used for integral approximations, but the reconstruction > filtering needed to make that integral *actually correct* is a prohibitively > difficult sinc (sin(t)/t) integration, and: It's always good to keep sampling theory in mind when working with digital systems. Here is a link for everyone: http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem In the material presented filtering is done on an already sampled set of points, and all the frequencies of the linear filtering via the svf and skf are kept below nyquist (the trapezoidal integration warps frequency and maps it to beep it below nyquist). Since the system is linear no harmonics are generated (apart from perhaps those caused by finite computation), so we are safely within the bounds specified by sampling theory, just like any other trapezoidal integrated linear filter, so I'm not sure why you bothered mentioning this at all since this applies equally to all dsp. > - using forward or other integration forms are going to sometimes make your > approximation scheme more stable in a control system (or an ongoing circuit > simulation) but are IN NO WAY going to make that integration error better > (except maybe by chance, or the opposite..). Numerical integration is a tradeoff of accuracy, computational effort, and stability, each different method has different things to offer. Being aware of the options is always a good thing so that informed decisions can be made when approaching each problem as to which is the best algorithm to use. In my examples I have tried to show people one option, trapezoidal, but also indicated other options are present as well that can easily fit into the same framework. This again seems to be a comment that isn't specific to the material presented, but just a generic comment about numerical integration so equally applies to all dsp that integrates, so all filters (things with caps or inductors or other time varying energy storage devices). > - Taking the currents through the capacitors as a measure for the network I used nodal analysis, so the currents over the amplifiers and capacitors are summed to solve the circuit. This is another name for KCL and is standard network theory. Do you have an observation to share about network theory? Perhaps there is a problem you would like to share on any shortcomings or issues you can see? The statement you made doesn't actually lead anywhere, and I'm not sure what point you are trying to make, so please help me out if you can (or anyone else that can see what Theo is trying to get at here, please help!) > - A state varying filter CANNOT just follow standard S-plane methods and > Z-transform equivalencies, because that theory is EXPLICITLY only valid for > stationary (non-dynamic) systems, and Please have a look at the algorithm and show me where I took a laplace transform to get to the discrete representation. The standard way circuit simulators solve (possibly non-linear) transient analysis does not use laplace transforms at all, but rather integrates the circuit equations directly. The statement you make sounds like a warning people about using DF1 biquads to me, which does operate through the laplace transform, and I couldn't agree more. The t
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 8/11/2013 4:29 AM, Theo Verelst wrote: Fine. He insulted run of the mill academic EE insights from decades ago, i merely stated facts, which should be respected, but here are still not. The theory is quite right, and I've taken the effort of correcting a lot of misinterpretations. I suppose that isn't popular. Hi Theo, I read your initial response to Andrew and it seems to me that it is *you* who is ignoring what he posted. Of course Andrew is making assumptions and of course this is all old news from an EE methods standpoint. But I think Andrew has been very clear on his sources. What you seem to be missing are the benefits of what Andrew is doing. To me these include: 1. "Novelty" in the world of open-access music-dsp algorithms that people can actually read about, use and learn from. Many people here don't have EE degrees -- and they certainly don't need one to follow the maths in Andrew's paper. Wasn't it you who just the other day criticised someone else for not providing a theoretical basis for their work? 2. Numerical performance even when using 32 bit floats (did you look at Andy's graphs of numerical performance vs DF1, DF2?). 3. Topology preservation: if you want to emulate a non-linear analog SVF without moving up to numerical integration techniques Andy's filter allows simple introduction of *approximate* static non-linearities. This is also generally useful for efficient implementation of "musical" filters, that often include static nonlinearities. 4. Stability under audio-rate time-varying coefficients. We recently discussed that you don't get this with "Dattoro approved" DF-1, DF-2, see Laroche's JAES paper on BIBO stability for details. Sure you get it with Lattice but that doesn't give you topology preservation if your source model is an SVF. Each of these points alone is interesting. When taken together I think that what Andy has posted is a really a useful contribution. It has got a better result than the status-quo. Personally I don't think this is really about the coefficient calculations, which I agree can be unified with higher-end s-plane/z-plane theory, it's about the combination of benefits above. In light of all this I really fail to see how your criticisms are even valid, let alone useful. Now, I do have one thing I would like to see: and that is a mathematical proof that point (4) above is actually true for this topology. Ever since I read the Laroche BIBO paper it scared the crap out of me to be modulating any IIR filter at audio rate without a trusted analysis. My 2 cents, Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
If popularity is a major point here: good manners are popular. They are simple to be put to good use, all of the time, under all circumstances. A typical application for them would be to keep criticizm or disagreement constructive. Inversely, bad manners have proven to obscure what otherwise may have been considered a point being made. /th Am 07.11.2013 um 18:29 schrieb Theo Verelst: > Phil Burk wrote: >> Dear Theo, >> >> I found Andrew's postings to be very interesting and helpful. >> >> . > > Fine. He insulted run of the mill academic EE insights from decades ago, i > merely stated facts, which should be respected, but here are still not. > > The theory is quite right, and I've taken the effort of correcting a lot of > misinterpretations. I suppose that isn't popular. > > T.V. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 11/7/13 9:29 AM, Theo Verelst wrote: Phil Burk wrote: Dear Theo, I found Andrew's postings to be very interesting and helpful. . Fine. He insulted run of the mill academic EE insights from decades ago, i merely stated facts, which should be respected, but here are still not. The theory is quite right, and I've taken the effort of correcting a lot of misinterpretations. I suppose that isn't popular. i find some interest i Andrew's analysis (and i've seen it longer ago when we were both corresponding with someone from Abelton about all this), and, although i have inferred *no* insult at all from Andrew's analysis, i have to agree a lot with Theo if the word "insulted" is perhaps replaced by "ignored". this is essentially an issue of mapping s to z and, while i understand that Bilinear Transform ain't the only way to do it, i also understand what the issues are using other methods, such as Euler's forward method or Predictor-Corrector or Impulse Invariant. and there are ways to directly compare. what Andrew is doing is about the same way we were dealing with modeling continuous-time analog circuits in class in the 1970s. i try to think about it in a more unified manner. coefficients for the SVF or any other 2nd-order form (like lattice and ladder) can be directly mapped to and from the coefficients of the DF1 or DF2. the form has nothing to do it how coefficients are determined. except for numerical issues regarding quantization related to *both* the coefficient values and the *signal* values. *that* is the reason for considering other forms than the Direct Forms. there are other issue to consider (like computational burden). but there is no necessary reason to be deriving coefficients directly for SVF because it can do something that the DF1 cannot regarding getting you the frequency response that you desire. my $0.02 . this isn't comp.dsp and i am much less interested in getting into any fights here about technical detail than is my interest in such at comp.dsp . (but i would like to maybe bring up a big philosophical disagreement i am having/exploring right now with the creator of JUCE about what it means to be modular and OOP. it's like we look at the same object and Jules says it's "white" and i say it's "black". it's a little similar the fundamental disagreement i have with the creator of MATLAB about the utility of integer indices below 1. i don't want to join a JUCE forum and do it, but i might be willing to invite Jules to this forum and slug it out here. or maybe it can be cross-posted to both forums.) -- r b-j r...@audioimagination.com "Imagination is more important than knowledge." -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
+1! On 07/11/2013 17:30, Victor Lazzarini wrote: +1 On 7 Nov 2013, at 17:16, Phil Burk wrote: Dear Theo, I found Andrew's postings to be very interesting and helpful. Respectful disagreement is welcome. Insults are not. Please stop. Thank you, Phil Burk -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Theo, How can one insult theory? If you think, Andrew is wrong, it won’t hurt to get the details. Now, you’re just insulting Andrew, which is not nice nor helpful. Steffan On 07.11.2013, at 18:29, Theo Verelst wrote: > Phil Burk wrote: >> Dear Theo, >> >> I found Andrew's postings to be very interesting and helpful. >> >> . > > Fine. He insulted run of the mill academic EE insights from decades ago, i > merely stated facts, which should be respected, but here are still not. > > The theory is quite right, and I've taken the effort of correcting a lot of > misinterpretations. I suppose that isn't popular. > > T.V. > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
I too appreciate Andrew's input. I'm sure that most here do as well. On Nov 7, 2013, at 9:11 AM, STEFFAN DIEDRICHSEN wrote: > I think, that’s not fair. Andrew has created some great products, just look > at his website http://www.cytomic.com. > To me, it’s an really interesting way to create algorithms by fusing things, > that come from MNA, with standard DSP stuff and some creative math. > > Steffan > > > On 07.11.2013, at 17:22, Theo Verelst wrote: > >> most of what you're oresenting is boring old crap, that isn't worth working >> on unless you'd actually understand some of the theory and relevant tunings >> involved. Clearly you don't. >> -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
+1 On 7 Nov 2013, at 17:16, Phil Burk wrote: > Dear Theo, > > I found Andrew's postings to be very interesting and helpful. > > Respectful disagreement is welcome. Insults are not. Please stop. > > Thank you, > Phil Burk > > On 11/7/13 8:22 AM, Theo Verelst wrote: >> most of what you're oresenting is boring old crap, that isn't worth >> working on unless you'd actually understand some of the theory and >> relevant tunings involved. Clearly you don't. >> -- >> dupswapdrop -- the music-dsp mailing list and website: >> subscription info, FAQ, source code archive, list archive, book reviews, >> dsp links >> http://music.columbia.edu/cmc/music-dsp >> http://music.columbia.edu/mailman/listinfo/music-dsp > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, dsp > links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Phil Burk wrote: Dear Theo, I found Andrew's postings to be very interesting and helpful. . Fine. He insulted run of the mill academic EE insights from decades ago, i merely stated facts, which should be respected, but here are still not. The theory is quite right, and I've taken the effort of correcting a lot of misinterpretations. I suppose that isn't popular. T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Dear Theo, I found Andrew's postings to be very interesting and helpful. Respectful disagreement is welcome. Insults are not. Please stop. Thank you, Phil Burk On 11/7/13 8:22 AM, Theo Verelst wrote: most of what you're oresenting is boring old crap, that isn't worth working on unless you'd actually understand some of the theory and relevant tunings involved. Clearly you don't. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
I think, that’s not fair. Andrew has created some great products, just look at his website http://www.cytomic.com. To me, it’s an really interesting way to create algorithms by fusing things, that come from MNA, with standard DSP stuff and some creative math. Steffan On 07.11.2013, at 17:22, Theo Verelst wrote: > most of what you're oresenting is boring old crap, that isn't worth working > on unless you'd actually understand some of the theory and relevant tunings > involved. Clearly you don't. > -- -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
most of what you're oresenting is boring old crap, that isn't worth working on unless you'd actually understand some of the theory and relevant tunings involved. Clearly you don't. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 7 November 2013 22:00, Theo Verelst wrote: > Andrew Simper wrote: >> >> On 6 November 2013 22:13, Theo Verelst wrote: >> >>> That's a lot of approximations and (to me !) unclear definitions on a >>> row. >> >> >> Ok, please let me know the first one you don't understand and I'll >> break it down for you! The only approximation made is the numerical >> integration scheme used ... > > > Did you even read what I wrote, or are you really that dumb ? > > > > T.V. I did read all your points, but none of them were specific to the material presented apart from the stupendously vague "Taking the currents through the capacitors as a measure for the network", but that didn't even seem to be a point to me since it is part of the method, unless you are trying to warn everyone that nodal circuit analysis is somehow flawed?!? So I thought it best to focus on breaking down the algorithm since I had little confidence you understood any of it (I did present it rather tersely). All the best, Andy -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Andrew Simper wrote: On 6 November 2013 22:13, Theo Verelst wrote: That's a lot of approximations and (to me !) unclear definitions on a row. Ok, please let me know the first one you don't understand and I'll break it down for you! The only approximation made is the numerical integration scheme used ... Did you even read what I wrote, or are you really that dumb ? T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
On 6 November 2013 22:13, Theo Verelst wrote: > That's a lot of approximations and (to me !) unclear definitions on a row. Ok, please let me know the first one you don't understand and I'll break it down for you! The only approximation made is the numerical integration scheme used (and that is always going to be an approximation by its very nature), the rest is basic circuit math on ideal components so does not contain any approximations at all. All the best, Andy -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Trapezoidal integrated optimised SVF v2
Andrew Simper wrote: Here is an updated version of the optimised trapezoidal integrated svf which bundles up all previous state into equivalent currents for the capacitors, which is how I solve non-linear circuits (although this solution is just the linear one that I'm posting here). The only thing to note that with trapezoidal integration you have gain terms of g = tan(pi*cutoff/samplerate) which become very large with high cutoff, so care needs to be taken if these "g" terms stand alone since the scaling can get large and could impact numerical performance: That's a lot of approximations and (to me !) unclear definitions on a row. Granted I like it when Network Theory (the EE kind) from the 50s and 60s and approximation methods from the 70s and 80s (for supercomputers) are put to good use, but I hope you are aware of the following theoretical limitations: - sampling theory states you can work in the z domain, taking z^-1 as a delay that can be used for integral approximations, but the reconstruction filtering needed to make that integral *actually correct* is a prohibitively difficult sinc (sin(t)/t) integration, and: - using forward or other integration forms are going to sometimes make your approximation scheme more stable in a control system (or an ongoing circuit simulation) but are IN NO WAY going to make that integration error better (except maybe by chance, or the opposite..). - Taking the currents through the capacitors as a measure for the network - A state varying filter CANNOT just follow standard S-plane methods and Z-transform equivalencies, because that theory is EXPLICITLY only valid for stationary (non-dynamic) systems, and - often changing the state of a filter system (or varying the characteristics of some component) implies there are frequency modulations taking place, which immediately lead to some amount (hopefully little!) of Bessel spectrum components, which, unfortunately, have unbounded spectrum, and therefore violate the "limited spectrum" rule of the main sampling theory. I'm all for Open Source work, so widely available examples are great, but all this EE stuff is theoretically no as easy as some seem to think! T.V. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] Trapezoidal integrated optimised SVF v2
Here is an updated version of the optimised trapezoidal integrated svf which bundles up all previous state into equivalent currents for the capacitors, which is how I solve non-linear circuits (although this solution is just the linear one that I'm posting here). The only thing to note that with trapezoidal integration you have gain terms of g = tan(pi*cutoff/samplerate) which become very large with high cutoff, so care needs to be taken if these "g" terms stand alone since the scaling can get large and could impact numerical performance: http://www.cytomic.com/files/dsp/SvfLinearTrapOptimised2.pdf Here is a similar thing done for a Sallen Key low pass: http://www.cytomic.com/files/dsp/SkfLinearTrapOptimised2.pdf Please note there is absolutely nothing new here, this is all standard circuit maths that has been around for ages, and all the maths behind it was invented by people like Netwon, Leibnitz, and Euler, they deserve all the credit and came up with ways of solving not just this linear case but also the non-linear case. Depending on what you are doing trapezoidal may not be the best integrator to use so most systems of solving these equations support several types of integrator. Here are some handy references: http://en.wikipedia.org/wiki/Capacitor http://en.wikipedia.org/wiki/Nodal_analysis http://qucs.sourceforge.net/tech/node26.html http://www.ecircuitcenter.com/SPICEtopics.htm Please let me know if there are any mistakes. Enjoy! Andy -- cytomic - sound music software -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
