Re: [music-dsp] Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Vadim Zavalishin

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] Analog versus digital systems (Ezra Buchla)

2013-11-11 Thread Theo Verelst
Sure, and I didn't call you dumb. I'm not dumb for being left out the 
Russian space program, or wanting to write a book without a alpha-degree 
or what else.. It's a hard area, which I why I've tried to make a few 
noticeable remarks, to shake the particular subject up a bit, so to speak.


If you're serious, I don't mind summing a few things up with practical 
application, no problem. Might even be fun.


But not at this moment. Maybe tomorrow.

One main thing for now, there's an interesting matter about the Switched 
Filter, primarily at the moment to broaden the attention, and to make 
the payload of this message enter in a more general digital and signal 
processing domain for musical (and other) applications:


 - Most digital systems as we now know them are Time Quantized (usually 
equally spaced times steps with impulse-based samples (for the sake of 
the Reconstruction theorem)), and Amplitude Quantized (vertical steps, 
like 16 bits for instance), for the sake of being able to use digital 
computers.


 - As a interesting comparison (for the effect) there are also 
Time-Quantized, Amplitude-Continuous processing chips since at least the 
early (Time Division Multiplexing) digital phones, of which my switched 
filter is an example. Clear difference: no vertical resolution to create 
quantization noise, and it is possible to nowadays buy chips that have 
digitally programmable *analog* signal path chips that may benefit from 
such tricks, possibly applicable in modern digital: amplifiers.


 - Of course there are, at least since music in the 60s I think, 
machines which do amplitude quantization only, like a grungelize 
sound, applying a staircase distortion to the signal, but *without* 
sampling the signal in the time dimension.


 - For modern attempts as clean analog signal paths *with* time-varying 
filters one can make use of digitally programmable amplifiers, like the 
Crystal/Burr-Brown half-dB step, fast digital control amplifier chips (a 
project of mine here, at about 1/3th of the page, only if you're 
interested: http://www.theover.org/Audio/index2.html ), using these 
chips instead of Operational Trans-conductance Amplifiers, digitally 
controlled analog filters may be created. The switching technique could 
add more resolution to this solution, and requires fast digital control 
and an analysis of the effects of applying digital dithering of such kind.


 - Of course the original of many software implementations of digitally 
controlled State Varying Filters (besides the fully analog Moogs and 
others), from early computer-controlled analog signal path music 
synthesizers on, has all kinds of tuning built in the control path of 
the filters (and other components like oscillators and VCAs). So a part 
of the question I asked myself was: how is it that those analog filters 
sound good (or bad if that's the will of the sound programmer), given 
that a part of the control signal path comes from digital control. For 
instance: what are the properties of the DA convertor that changes a 
know-turn on the computer side of the instrument, into an electrical 
signal to drive the cut-off control line of the filter circuit.


Gr.

  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] R: Time Varying BIBO Stability Analysis of Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Marco Lo Monaco
Hi Ross/Andrew,
I couldnt wait to put my hands on it :) (the creativity/curiosity spark is
always lit)

Here is my MuPad notebook :

https://www.dropbox.com/s/er1s0aeheuv3igg/VCF-StateVariableFilter.pdf

I basically demonstrate what I already said in my previous posts.
The standard state-space approach leads to identical results to your
algorithm, I would say even without the trick of the TPT, because of course
we are talking about an instantaneous _linear_ feedback.
That makes sense: my ABCD statespace matrixes are identical to yours,
same thing applies for CPU load in terms of MULs/ADDs.

Of course the main purpose of my analysis was to keep in mind that you will
_always_ have to deal with an implicit/hidden inversion of a matrix A of
the analog system (actually (I-A*h/2)) of the same order of your system,
which in this SVF fortunate case is 2 and also easy. For a moment think
about an analog system who has 10 capacitors and you want it to change it at
audio rate: you will have to deal with a0,a1,a2... coeffs that will be
rationaly polynomials, meaning lots of DIVs at runtime). Generally speaking,
inverting a matrix at audio rate is not a good idea :)

As I already said, we agree that these approaches are dated a long ago.

Ross showed the same results of matrix A,B (he didn't showed C,D because
they are not needed for the Laroche BIBO analysis). His results match my
same ones.

Sorry if I omitted some code in collecting state/in/out variables in your
original algo, but I already got 6 pages of pdf this way and I thought it
would have been a good idea to keep it simple.

Hope to have helped you clear my my point of view.

Ciao

Marco


-Messaggio originale-
Da: music-dsp-boun...@music.columbia.edu
[mailto:music-dsp-boun...@music.columbia.edu] Per conto di Ross Bencina
Inviato: domenica 10 novembre 2013 16:58
A: A discussion list for music-related DSP
Oggetto: [music-dsp] Time Varying BIBO Stability Analysis of Trapezoidal
integrated optimised SVF v2

Hi Everyone,

I took a stab at converting Andrew's SVF derivation [1] to a state space
representation and followed Laroche's paper to perform a time varying BIBO
stability analysis [2]. Please feel free to review and give feedback. I only
started learning Linear Algebra recently.

Here's a slightly formatted html file:

http://www.rossbencina.com/static/junk/SimperSVF_BIBO_Analysis.html

And the corresponding Maxima worksheet:

http://www.rossbencina.com/static/junk/SimperSVF_BIBO_Analysis.wxm

I had to prove a number of the inequalities by cut and paste to Wolfram
Alpha, if anyone knows how to coax Maxima into proving the inequalities I'm
all ears. Perhaps there are some shortcuts to inequalities on rational
functions that I'm not aware of. Anyway...

The state matrix X:

[ic1eq]
[ic2eq]

The state transition matrix P:

[-(g*k+g^2-1)/(g*k+g^2+1), -(2*g)/(g*k+g^2+1) ]
[(2*g)/(g*k+g^2+1),(g*k-g^2+1)/(g*k+g^2+1)]

(g  0, k  0 = 2)

Laroche's method proposes two time varying stability criteria both using the
induced Euclidian (p2?) norm of the state transition matrix:

Either:

Criterion 1: norm(P)  1 for all possible state transition matrices.

Or:

Criterion 2: norm(TPT^-1)  1 for all possible state transition matrices,
for some fixed constant change of basis matrix T.

norm(P) can be computed as the maximum singular value or the positive square
root of the maximum eigenvalue of P.transpose(P). I've taken a shortcut and
not taken square roots since we're testing for norm(P) strictly less than 1
and the square root doesn't change that.

 From what I can tell norm(P) is 1, so the trapezoidal SVF filter fails to
meet Criterion 1.

The problem with Criterion 2 is that Laroche doesn't tell you how to find
the change of basis matrix T. I don't know enough about SVD, induced p2 norm
or eigenvalues of P.P' to know whether it would even be possible to cook up
a T that will reduce norm(P) for all possible transition matrices. Is it
even possible to reduce the norm of a unit-norm matrix by changing basis?

 From reading Laroche's paper it's not really clear whether there is any way
to prove Criterion 2 for a norm-1 matrix. He kind-of side steps the issue
with the norm=1 Normalized Ladder and ends up proving that norm(P^2)1. This
means that the Normalized Ladder is time-varying BIBO stable for parameter
update every second sample.

Using Laroche's method I was able to show that Andrew's trapezoidal SVF
(state transition matrix P above) is also BIBO stable for parameter update
every second sample. This is the final second of the linked file above.

If anyone has any further insights on Criterion 2 (is it possible that T
could exist?) I'd be really interested to hear about it.

Constructive feedback welcome :)

Thanks,

Ross


[1] Andrew Simper trapazoidal integrated SVF v2
http://www.cytomic.com/files/dsp/SvfLinearTrapOptimised2.pdf

[2] On the Stability of Time-Varying Recursive Filters
http://www.aes.org/e-lib/browse.cfm?elib=14168
--
dupswapdrop -- 

Re: [music-dsp] Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Urs Heckmann

On 11.11.2013, at 02:21, robert bristow-johnson r...@audioimagination.com 
wrote:

 On 11/10/13 5:12 PM, Urs Heckmann wrote:
 On 11.11.2013, at 01:33, robert bristow-johnsonr...@audioimagination.com  
 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] Time Varying BIBO Stability Analysis of Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Vadim Zavalishin

Hi Ross,

since you opened this topic, I thought I'd try to share the intermediate 
results my findings, as much as I can remember them (that was a few 
years back). Most of them concern the continuous time case.


First note regarding the continuous time case is that cutoff modulations 
do not affect the BIBO stability at all. More rigorously:
- if the cutoff modulation is done by varying the gains *in front* 
(rather than behind) of *all* integrators in the system

- if the cutoff function w(t) is always positive
- if the system is BIBO stable for some cutoff function w(t)
then the system is also BIBO stable for any other positive cutoff function

Particularly, if a linear system is BIBO-stable in time-invariant case 
(for the constant cutoff function), then it's also stable for varying 
cutoff.


This is very easy to obtain from the state-space equation:
du/dt=w*F(u,x)
where u(t) is the state vector, x(t) is the input vector, w(t) is the 
cutoff scalar function and F(u,x,t) is the nonlinear time-varying 
version of A*u+B*x. Without reduction of generality we can assume w(t)=1 
for the given stable case. Then, we simply rewrite the equation as

du/(w*dt)=F(u,x)
and substitute the time parameter:
d tau = w*dt
Now in tau time coordinates the modulated system is exactly the same 
as the unmodulated one in the t coordinates.


The same doesn't seem to hold for the TPT discrete-time version, though.


In a more general case for *linear* continuous time, IIRC, we have a 
sufficient (but it seems, not necessary) time-varying stability 
criterion: all eigenvalues of the matrix A+A^T must be uniformly 
negative, that is they must be bounded by some negative number from 
above. It is essential to require this uniform negativity, otherwise the 
eigenvalues can get arbitrarily close to the self-oscillation case. This 
condition is simply obtained from the fact that in the absence of the 
input signal you want the absolute value of the state to decay with a 
relative speed, which is uniformly less that 1. This will make sure, 
that, whatever the bound of the input signal is, a large enough state 
will decay sufficiently fast, to win over the input vector B(t)*x(t). 
Indeed, ignoring the B*x term, we have

(d/dt) |u|^2=(d/dt)(u^T*u)=u'^T*u+u^T*u'=
(A*u)^T*u+u^T*(A*u)=u^T*A^T*u+u^T*A*u=
u^T*(A+A^T)*u=|u|^2*max{lambda_i}
where lambda_i are the eigenvalues of A+A^T.
Now on the other hand
(d/dt) |u|^2=2*|u|*(d/dt)|u|
So
2*|u|*(d/dt)|u|=|u|^2*max{lambda_i}
and
2*(d/dt)|u|=|u|*max{lambda_i}

Obviously, you don't have to satisfy the condition in the original 
state-space coordinates. Instead, you can satisfy it in any other 
coordinates, which corresponds to using P^T*A*P instead of A for some 
nonsingular matrix P.


Now I didn't manage to get this condition satisfied for the 
continuous-time SVF. Reading your post, I admit, that I could have made 
a mistake there, but FWIW... First, I discarded the consideration of 
varying cutoff, as explained above and concentrated on the varying 
damping. Not managing to find a matrix P, I constructed an input signal, 
requiring the maximum possible growth of the state vector. The signal, 
IIRC was either sgn(s_1) or -sgn(s_1), where s_1 is the first of the 
state components (or it could have been s_2). Then I noticed that for 
low damping the state vector is moving in almost a circle, while for 
higher damping (but still with complex poles) is turns into an ellipse. 
This was exactly the problem: in principle the circle is having a 
bigger size, than the ellipse, but by switching the damping from low to 
high you could shoot the state point into a much higher orbit. Much 
worse, in certain cases the system state can increase even in the full 
absence of the input signal!!! However, IIRC, I managed to show, that 
for a sufficiently large elliptic orbit (with high damping), 
(d/dt)|u|^2=0 regardless of the current damping. Since we are already 
considering the worst possible input signal, the system state can't 
cross this boundary orbit to the outside.


For the discrete-time case the situation is more complicated, because we 
can't use the continuity of the state vector function. IIRC, I also 
didn't manage to build the worst-case signal, but there was the same 
problem of the state vector becoming larger in the absence of the input 
signal. That's why I was somewhat surprised that you simply managed to 
restrict the eigenvalues of the system matrix in some coordinates. 
Particularly suspicious is that your coordinate transformation matrix is 
built for the smallest damping, while the more problematic case seems 
to occur at the larger damping. But, as I said, I didn't finish that 
research and I could have been wrong. So just take my input FWIW.


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, 

Re: [music-dsp] R: Time Varying BIBO Stability Analysis of Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Vadim Zavalishin

Hi Marco

On 11-Nov-13 11:26, Marco Lo Monaco wrote:

I basically demonstrate what I already said in my previous posts.
The standard state-space approach leads to identical results to your
algorithm, I would say even without the trick of the TPT, because of course
we are talking about an instantaneous _linear_ feedback.


Of course they are all equivalent, except for some small detail, as e.g. 
the usage of canonical integrators (although maybe even that was known 
for long time for trapezoidal integration).



Of course the main purpose of my analysis was to keep in mind that you will
_always_ have to deal with an implicit/hidden inversion of a matrix A of
the analog system (actually (I-A*h/2))


With the filters used in practice, the matrices typically turn out to be 
either simple or have quite regular structures. This often is given for 
granted in the 0df (TPT) approach, as you are just solving one linear 
feedback equation, instead of trying to invert a 5x5 matrix etc. Of 
course, it's mathematically equivalent, but is much simpler. Also, the 
division (the most expensive operation) which you have to perform while 
solving that equation is more or less the same division by a0 which you 
need to perform in the computation of the BLT-based discrete-time 
coefficients. So, computationally I think the 0df approach is comparable 
(even if slighly more expensive at times) to the transfer-function based 
DF filters, expecially at audio-rate modulations.


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

2013-11-11 Thread Theo Verelst

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

2013-11-11 Thread Vadim Zavalishin

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] Time Varying BIBO Stability Analysis of Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Ross Bencina

Hi Vadim,

Thanks for your feedback...

On 11/11/2013 9:52 PM, Vadim Zavalishin wrote:
[snip on the analog stuff]


For the discrete-time case the situation is more complicated, because we
can't use the continuity of the state vector function. IIRC, I also
didn't manage to build the worst-case signal, but there was the same
problem of the state vector becoming larger in the absence of the input
signal.


Interesting


That's why I was somewhat surprised that you simply managed to
restrict the eigenvalues of the system matrix in some coordinates.


To be clear: the eigenvalues of the transition matrix only cover 
time-invariant stability.


The constraint for time-varying BIBO stability is that all transition 
matrices P satisfy ||TPT^-1||  1 where ||.|| is the spectral norm and T 
is some constant non-singular change of base matrix.


The main reason I am suspicious is that Laroche does not even try to 
cook up a change of basis matrix, or to show when it might be achieved. 
It's kind of an orphan result in that paper that goes unused for showing 
BIBO stability.



Particularly suspicious is that your coordinate transformation matrix is
built for the smallest damping, while the more problematic case seems
to occur at the larger damping.


I'm not sure I follow you here. Smallest damping means most resonance, 
where the system decays most slowly. Don't you think this would be where 
the greatest problems would arise?


 But, as I said, I didn't finish that

research and I could have been wrong. So just take my input FWIW.


I have made a slightly cleaner cook-up of the change of basis matrix. 
This seems a lot like the uniformly negative criteria you mentioned. 
It could be read that k must be uniformly positive:


http://www.rossbencina.com/static/junk/2x2ChangedBasisNorm.html

In short, using change of basis matrix T:
[1 f]
[0 1]

We have the time-varying BIBO stability constraint:

0  f  2, g  0, f  k = 2

f provides the bound on k from below.

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] Time Varying BIBO Stability Analysis of Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Vadim Zavalishin

On 11-Nov-13 15:32, Ross Bencina wrote:

That's why I was somewhat surprised that you simply managed to
restrict the eigenvalues of the system matrix in some coordinates.


To be clear: the eigenvalues of the transition matrix only cover
time-invariant stability.

The constraint for time-varying BIBO stability is that all transition
matrices P satisfy ||TPT^-1||  1 where ||.|| is the spectral norm and T
is some constant non-singular change of base matrix.


Okay, for the time-varying case it seems to be the eigenvalues of 
(P^T)*P in the discrete-time case, which according to Wikipedia define 
the spectral norm (while in the continuous time we have the eigenvalues 
of P^T+P). I'm currently a little short of time to take a precise look 
at all the details. Still, in both cases we are talking about some 
uniform property of eigenvalues of a symmetric matrix. In the discrete 
time they need to be smaller than one to kind of make sure the next 
state vector is smaller than the previous one (I think). In the 
continuous time case they need to be negative to kind of make sure that 
the time derivative of the state vector's length is negative.




The main reason I am suspicious is that Laroche does not even try to
cook up a change of basis matrix, or to show when it might be achieved.
It's kind of an orphan result in that paper that goes unused for showing
BIBO stability.


IIRC from briefly reading his paper, his sufficient criterion turned out 
to be not applicable for the DF filters (which by themselves also didn't 
seem to be time-variant BIBO-stable, IIRC), therefore he resorted to 
some other approaches. That (and my own SVF investigation) led me to 
consider this kind of criterion as a more or less useless one at that 
time. But I may be wrong, it was a while ago and only a brief look.





Particularly suspicious is that your coordinate transformation matrix is
built for the smallest damping, while the more problematic case seems
to occur at the larger damping.


I'm not sure I follow you here. Smallest damping means most resonance,
where the system decays most slowly. Don't you think this would be where
the greatest problems would arise?


Because of the shooting effect I described earlier. I discovered it by 
a numerical simulation of the system. For the low resonance the state 
vector moves in an ellipse (for the worst-case signal I described). 
The orientation and the amount of stretching of the ellipse depends on 
the resonance (the lower the resonance the more the stretch). You can 
suddenly switch to a lower resonance while your state vector is pointing 
at such angle, that the respective position on the new ellipse is within 
the increasing radius area. This will cause the state vector to grow.


Disclaimer: this all goes under the notice that I didn't double-check my 
results or may even have forgotten some important details or simply 
remember them wrong. I was posting them mostly because I thought they 
might be interesting and/or usable to some extent for you (and maybe 
others).




In short, using change of basis matrix T:
[1 f]
[0 1]

We have the time-varying BIBO stability constraint:

0  f  2, g  0, f  k = 2

f provides the bound on k from below.


This is also the kind of the result which I would intuitively expect at 
the first thought. It's just contradicting the *unverified* results of 
my earlier research, that's why I expressed my suspiciousness. 
Hopefully, I'll find time to check your research in more detail.


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

2013-11-11 Thread Dave Gamble

On Monday, November 11, 2013, Urs Heckmann wrote:


 On 11.11.2013, at 01:33, robert bristow-johnson r...@audioimagination.com 
 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

2013-11-11 Thread Dave Gamble

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, book reviews, dsp 
links

Re: [music-dsp] Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Vadim Zavalishin

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


[music-dsp] [admin] HTML test

2013-11-11 Thread douglas repetto


This is an html email. If you're reading the list in a plaintext only 
client, please let me know if you can't read this message. (JOKE!)



best,
douglas


--
... 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


[music-dsp] [admin] plain text test

2013-11-11 Thread douglas repetto


I just sent a message to the list using HTML. If you use a plain text 
only client and could not read it, please let me know.



best,
douglas


--
... 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


Re: [music-dsp] [admin] HTML test

2013-11-11 Thread Dave Gamble
Hi,

On 11 Nov 2013, at 17:09, douglas repetto doug...@music.columbia.edu wrote:

 
 This is an html email. If you're reading the list in a plaintext only client, 
 please let me know if you can't read this message. (JOKE!)
 
It might have been an html email originally, but what arrived here is not HTML, 
nor even multipart.

What arrived in my inbox here (this is Apple's Mail.app, which allows me to 
browse raw source) is a plaintext email.

Did my email help then? :D

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] Your message to music-dsp awaits moderator approval

2013-11-11 Thread STEFFAN DIEDRICHSEN
I think, I stretched it …

Steffan 
On 11.11.2013, at 18:15, music-dsp-boun...@music.columbia.edu wrote:

 Your mail to 'music-dsp' with the subject
 
Fun with HTML
 
 Is being held until the list moderator can review it for approval.
 
 The reason it is being held:
 
Message body is too big: 471030 bytes with a limit of 40 KB
 
 Either the message will get posted to the list, or you will receive
 notification of the moderator's decision.  If you would like to cancel
 this posting, please visit the following URL:

--
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] [admin] another HTML test

2013-11-11 Thread douglas repetto


Hi Dave,

I have the list set to convert HTML mail to plain text. So it's a good 
sign that the email went through. I'm composing this in red text and 
changing fonts around. That should all disappear when this message 
arrives...


Here's a list:

1. * taco
2. * truck



Wheee!



--
... 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


Re: [music-dsp] Your message to music-dsp awaits moderator approval

2013-11-11 Thread douglas repetto


Okay, that's just because the message was too large. Note that the HTML 
is actually being stripped out, so crazy formatting will be removed.



On 11/11/13 12:16 PM, STEFFAN DIEDRICHSEN wrote:

I think, I stretched it …

Steffan
On 11.11.2013, at 18:15, music-dsp-boun...@music.columbia.edu wrote:


Your mail to 'music-dsp' with the subject

Fun with HTML

Is being held until the list moderator can review it for approval.

The reason it is being held:

Message body is too big: 471030 bytes with a limit of 40 KB

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:

--
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



--
... 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


Re: [music-dsp] [admin] another HTML test

2013-11-11 Thread douglas repetto


Okay, it seems to be working. You can now post to the list in HTML but 
your message will be converted to plain text. This seems like a good 
first step to accommodate people who need plain text and people for whom 
sending plain text is a pain. I tried to respond to some message from my 
phone while I was out of town and found that it's impossible to send 
plain text email that way!


best,
douglas




On 11/11/13 12:16 PM, douglas repetto wrote:


Hi Dave,

I have the list set to convert HTML mail to plain text. So it's a good 
sign that the email went through. I'm composing this in red text and 
changing fonts around. That should all disappear when this message 
arrives...


Here's a list:

1. * taco
2. * truck



Wheee!





--
... 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


Re: [music-dsp] [admin] another HTML test

2013-11-11 Thread douglas repetto


Oh, and I've turned on notification for bounced messages. Hopefully we 
won't clog up the server too much. In the past we've had thousands of 
robots hammering on the server 24/7.


best,
douglas




On 11/11/13 12:16 PM, douglas repetto wrote:


Hi Dave,

I have the list set to convert HTML mail to plain text. So it's a good 
sign that the email went through. I'm composing this in red text and 
changing fonts around. That should all disappear when this message 
arrives...


Here's a list:

1. * taco
2. * truck



Wheee!





--
... 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


Re: [music-dsp] [admin] another HTML test

2013-11-11 Thread Thomas Young
Thanks Doug :)



-Original Message-
From: music-dsp-boun...@music.columbia.edu 
[mailto:music-dsp-boun...@music.columbia.edu] On Behalf Of douglas repetto
Sent: 11 November 2013 17:19
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] [admin] another HTML test





Okay, it seems to be working. You can now post to the list in HTML but your 
message will be converted to plain text. This seems like a good first step to 
accommodate people who need plain text and people for whom sending plain text 
is a pain. I tried to respond to some message from my phone while I was out of 
town and found that it's impossible to send plain text email that way!



best,

douglas









On 11/11/13 12:16 PM, douglas repetto wrote:



 Hi Dave,



 I have the list set to convert HTML mail to plain text. So it's a good

 sign that the email went through. I'm composing this in red text and

 changing fonts around. That should all disappear when this message

 arrives...



 Here's a list:



 1. * taco

 2. * truck







 Wheee!









--

... 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] [admin] another HTML test

2013-11-11 Thread Dave Gamble
Indeed, it appears to be +completely+ impossible to send non-multipart
plaintext email from iOS using the Mail app there, or even the gmail app.

Dave.


On Mon, Nov 11, 2013 at 5:19 PM, douglas repetto doug...@music.columbia.edu
 wrote:


 Okay, it seems to be working. You can now post to the list in HTML but
 your message will be converted to plain text. This seems like a good first
 step to accommodate people who need plain text and people for whom sending
 plain text is a pain. I tried to respond to some message from my phone
 while I was out of town and found that it's impossible to send plain text
 email that way!

 best,
 douglas





 On 11/11/13 12:16 PM, douglas repetto wrote:


 Hi Dave,

 I have the list set to convert HTML mail to plain text. So it's a good
 sign that the email went through. I'm composing this in red text and
 changing fonts around. That should all disappear when this message
 arrives...

 Here's a list:

 1. * taco
 2. * truck



 Wheee!




 --
 ... 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] [admin] another HTML test

2013-11-11 Thread Reid Oda
Yes thank you! ...and all this time I thought my questions were simply
uninteresting.

On Mon, Nov 11, 2013 at 12:20 PM, Thomas Young
thomas.yo...@rebellion.co.uk wrote:
 Thanks Doug :)



 -Original Message-
 From: music-dsp-boun...@music.columbia.edu 
 [mailto:music-dsp-boun...@music.columbia.edu] On Behalf Of douglas repetto
 Sent: 11 November 2013 17:19
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] [admin] another HTML test





 Okay, it seems to be working. You can now post to the list in HTML but your 
 message will be converted to plain text. This seems like a good first step to 
 accommodate people who need plain text and people for whom sending plain text 
 is a pain. I tried to respond to some message from my phone while I was out 
 of town and found that it's impossible to send plain text email that way!



 best,

 douglas









 On 11/11/13 12:16 PM, douglas repetto wrote:



 Hi Dave,



 I have the list set to convert HTML mail to plain text. So it's a good

 sign that the email went through. I'm composing this in red text and

 changing fonts around. That should all disappear when this message

 arrives...



 Here's a list:



 1. * taco

 2. * truck







 Wheee!









 --

 ... 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



-- 
Reid Oda
Ph.D. Candidate
Princeton University
858-349-2037
http://www.cs.princeton.edu/~roda
--
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] [admin] another HTML test

2013-11-11 Thread douglas repetto


Same with the stock Android mail client.

On 11/11/13 12:20 PM, Dave Gamble wrote:

Indeed, it appears to be +completely+ impossible to send non-multipart
plaintext email from iOS using the Mail app there, or even the gmail app.

Dave.


On Mon, Nov 11, 2013 at 5:19 PM, douglas repetto doug...@music.columbia.edu

wrote:




Okay, it seems to be working. You can now post to the list in HTML but
your message will be converted to plain text. This seems like a good first
step to accommodate people who need plain text and people for whom sending
plain text is a pain. I tried to respond to some message from my phone
while I was out of town and found that it's impossible to send plain text
email that way!

best,
douglas





On 11/11/13 12:16 PM, douglas repetto wrote:



Hi Dave,

I have the list set to convert HTML mail to plain text. So it's a good
sign that the email went through. I'm composing this in red text and
changing fonts around. That should all disappear when this message
arrives...

Here's a list:

1. * taco
2. * truck



Wheee!





--
... 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



--
... 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


[music-dsp] Fwd: [admin] another HTML test

2013-11-11 Thread STEFFAN DIEDRICHSEN


Begin forwarded message:

 From: STEFFAN DIEDRICHSEN sdiedrich...@mac.com
 Subject: Re: [music-dsp] [admin] another HTML test
 Date: 11. November 2013 18:20:14 MEZ
 To: A discussion list for music-related DSP music-dsp@music.columbia.edu
 
 Does this apply to rich text mails as well? That was the problem with Mail 
 here.
 
 Steffan 
 
 
 
 On 11.11.2013, at 18:19, douglas repetto doug...@music.columbia.edu wrote:
 
 
 Okay, it seems to be working. You can now post to the list in HTML but your 
 message will be converted to plain text. This seems like a good first step 
 to accommodate people who need plain text and people for whom sending plain 
 text is a pain. I tried to respond to some message from my phone while I was 
 out of town and found that it's impossible to send plain text email that way!
 
 best,
 douglas
 
 
 
 
 On 11/11/13 12:16 PM, douglas repetto wrote:
 
 Hi Dave,
 
 I have the list set to convert HTML mail to plain text. So it's a good sign 
 that the email went through. I'm composing this in red text and changing 
 fonts around. That should all disappear when this message arrives...
 
 Here's a list:
 
 1. * taco
 2. * truck
 
 
 
 Wheee!
 
 
 
 
 -- 
 ... 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] Fwd: [admin] another HTML test

2013-11-11 Thread douglas repetto


Yes, it should convert rich text to plain text. Can you send a test 
message? At the least it should send you back a bounce message.


best,
douglas



On 11/11/13 12:22 PM, STEFFAN DIEDRICHSEN wrote:



Begin forwarded message:


From: STEFFAN DIEDRICHSEN sdiedrich...@mac.com
Subject: Re: [music-dsp] [admin] another HTML test
Date: 11. November 2013 18:20:14 MEZ
To: A discussion list for music-related DSP music-dsp@music.columbia.edu

Does this apply to rich text mails as well? That was the problem with Mail here.

Steffan



On 11.11.2013, at 18:19, douglas repetto doug...@music.columbia.edu wrote:



Okay, it seems to be working. You can now post to the list in HTML but your 
message will be converted to plain text. This seems like a good first step to 
accommodate people who need plain text and people for whom sending plain text 
is a pain. I tried to respond to some message from my phone while I was out of 
town and found that it's impossible to send plain text email that way!

best,
douglas




On 11/11/13 12:16 PM, douglas repetto wrote:


Hi Dave,

I have the list set to convert HTML mail to plain text. So it's a good sign 
that the email went through. I'm composing this in red text and changing fonts 
around. That should all disappear when this message arrives...

Here's a list:

1. * taco
2. * truck



Wheee!





--
... 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



--
... 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


Re: [music-dsp] Fwd: [admin] another HTML test

2013-11-11 Thread STEFFAN DIEDRICHSEN
Rich t  textTest. .
Should be red. If not, all is well. 

Steffan  
On 11.11.2013, at 18:23, douglas repetto doug...@music.columbia.edu wrote:

 
 Yes, it should convert rich text to plain text. Can you send a test message? 
 At the least it should send you back a bounce message.
 
 best,
 douglas
 
 
 
 On 11/11/13 12:22 PM, STEFFAN DIEDRICHSEN wrote:
 
 
 Begin forwarded message:
 
 From: STEFFAN DIEDRICHSEN sdiedrich...@mac.com
 Subject: Re: [music-dsp] [admin] another HTML test
 Date: 11. November 2013 18:20:14 MEZ
 To: A discussion list for music-related DSP music-dsp@music.columbia.edu
 
 Does this apply to rich text mails as well? That was the problem with Mail 
 here.
 
 Steffan
 
 
 
 On 11.11.2013, at 18:19, douglas repetto doug...@music.columbia.edu wrote:
 
 
 Okay, it seems to be working. You can now post to the list in HTML but 
 your message will be converted to plain text. This seems like a good first 
 step to accommodate people who need plain text and people for whom sending 
 plain text is a pain. I tried to respond to some message from my phone 
 while I was out of town and found that it's impossible to send plain text 
 email that way!
 
 best,
 douglas
 
 
 
 
 On 11/11/13 12:16 PM, douglas repetto wrote:
 
 Hi Dave,
 
 I have the list set to convert HTML mail to plain text. So it's a good 
 sign that the email went through. I'm composing this in red text and 
 changing fonts around. That should all disappear when this message 
 arrives...
 
 Here's a list:
 
 1. * taco
 2. * truck
 
 
 
 Wheee!
 
 
 
 
 --
 ... 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
 
 
 -- 
 ... 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


[music-dsp] R: Trapezoidal integrated optimised SVF v2

2013-11-11 Thread Marco Lo Monaco
Hi Dave,
Agreed on Vadim's interpretation of the mktg gimmick about the zdf/whatever
acronyms (btw: it took me a while to understand the 0df wasnt a hex
number!!! :) )
As I already told in my previous post, according to my knowledge the free
delay loop (which implies instantaneous feedback) term has been forged in
the 1970s by Mitra.
The Serafini's/Simper/Vadim's method for linear case we all know that is
equivalent to the classic SS formulation. Classic approach use voltages on
capacitors passing thru ABCD diff eqs system, while the straight integration
(via blt) uses capacitor currents, but the ABCD formalism in the discrete
time is equivalent.
As far as the nonlinear case is concerned, maybe Serafini was the first to
use the same technique (straight discretization from diff eqs).
But (again I want to restate this for sake of completion) the formalism was
designed even much before him, by De Poli/Rocchesso et alias in the mid
1990s.
Those techniques (recently extended by Yeh in his phd thesis) have strong
formalism and theory behind (as well as statespace has): it's a rich
technique and there are some theorems (which I guess not very well known in
the community) that let the overall theory be used in a very wide
application field (i.e. even to system with nonlinearity _with_ memory).

The fictious delay inserted in the loop is still used around - I think -
especially in those cases where the bandwidth of the feedback signal is low
compared to the audio rate (i.e. envelope followers and NOT the case of moog
ladder).  Adding a unit delay in the feedback filter which is not somewhat
intended to be a delay fx to me it's a big mistake and I don’t get any
surprise realizing that the final magnitude responses are so far off as to
be worthless
In the other cases where low bandwidth is practical, even if not the best
theoretic solution, I guess it is a good trade off since in some
circumstances the signal can be really considered quasi-static between two
samples and gives a benefit in the cpu cost.

Ciaoo
Marco

-Messaggio originale-
Da: music-dsp-boun...@music.columbia.edu
[mailto:music-dsp-boun...@music.columbia.edu] Per conto di Dave Gamble
Inviato: lunedì 11 novembre 2013 17:33
A: A discussion list for music-related DSP
Oggetto: 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 

[music-dsp] Tenure-Track Audio/Multimedia Engineer position at UVA

2013-11-11 Thread Ryan Maguire
Hey Music-DSP folks,

The University of Virginia McIntire Department of Music is still accepting
applications for a tenure-track Audio/Multimedia Engineer. See below for
more information.

- Ryan
-

The University of Virginia McIntire Department of Music invites
applications for a tenure-track position of Assistant Professor in
Audio and Multimedia Engineering. We seek a colleague who will enrich our
graduate and undergraduate programs in Composition and Computer
Technologies (CCT), and engage productively with a vibrant and diverse
music department as well as other arts, sciences, engineering, or
humanities disciplines at the University. The fields of specialization
might include, but are not limited to, human-computer interaction, sound
synthesis, sonification, mobile computing and applications, audio-visual
systems, network music, artificial intelligence, new interfaces for musical
expression, new musical hardware, music and gaming, and musical
robotics. Candidates should have a strong background in music and
experimental artistic practices.

Responsibilities will include research, undergraduate and graduate
teaching, and faculty service. Review of applications will begin on October
30, 2013, and applications will be accepted until the position is filled.
The position begins August 25, 2014. Applicants must be on track to hold a
doctorate in engineering, computer science, computer music, digital arts,
or related field by the time of appointment. University teaching experience
is desired.

For information on the University of Virginia see: http://www.virginia.edu.
For information on the McIntire Department of Music see: http://music.
virginia.edu.

To apply candidates must submit a Candidate Profile through Jobs@ UVA (
https://jobs.virginia.edu), search on posting number 0613013, and
electronically attach the following: a cover letter of interest describing
research agenda and teaching experience, a curriculum vitae, and contact
information for three references. In addition, please arrange to have three
confidential letters of recommendation sent to Audio Engineering Search,
McIntire Department of Music, P.O. Box 400176, University ofVirginia,
Charlottesville,
VA 22904-4176.

Questions regarding the application process in JOBS@UVa should be directed
to Heather Hodges, hm...@virginia.edu, 424-924-3052.

The University will perform background checks on all new faculty hires prior
to making a final offer of employment.

Contact Information: Matthew Burtner, Chair, Audio and Multimedia
Engineering Search Committee, mburt...@virginia.edu, (434) 924-3052.

The College of Arts  Sciences and the University of Virginia is an Equal
Opportunity/Affirmative Action employer. We are committed to developing
diversity in faculty and staff and welcome applications from women,
minorities, veterans and persons with disabilities.
--
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

2013-11-11 Thread Andrew Simper
On 11 November 2013 08:09, robert bristow-johnson
r...@audioimagination.com wrote:
 On 11/8/13 6:47 PM, Andrew Simper wrote:

 On 9 November 2013 08:57, Tom Duffytdu...@tascam.com  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
 f0Fs, even floating point doesn't help.  all of the information concerning
 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.


Re: [music-dsp] Fwd: [admin] another HTML test

2013-11-11 Thread Andrew Simper
(sent in html)

Thanks Douglas! This is a huge help.

All the best,

Andy
--
cytomic - sound music software


On 12 November 2013 01:26, STEFFAN DIEDRICHSEN sdiedrich...@me.com wrote:

 Rich t  textTest. .
 Should be red. If not, all is well.

 Steffan
 On 11.11.2013, at 18:23, douglas repetto doug...@music.columbia.edu
 wrote:

 
  Yes, it should convert rich text to plain text. Can you send a test
 message? At the least it should send you back a bounce message.
 
  best,
  douglas
 
 
 
  On 11/11/13 12:22 PM, STEFFAN DIEDRICHSEN wrote:
 
 
  Begin forwarded message:
 
  From: STEFFAN DIEDRICHSEN sdiedrich...@mac.com
  Subject: Re: [music-dsp] [admin] another HTML test
  Date: 11. November 2013 18:20:14 MEZ
  To: A discussion list for music-related DSP 
 music-dsp@music.columbia.edu
 
  Does this apply to rich text mails as well? That was the problem with
 Mail here.
 
  Steffan
 
 
 
  On 11.11.2013, at 18:19, douglas repetto doug...@music.columbia.edu
 wrote:
 
 
  Okay, it seems to be working. You can now post to the list in HTML
 but your message will be converted to plain text. This seems like a good
 first step to accommodate people who need plain text and people for whom
 sending plain text is a pain. I tried to respond to some message from my
 phone while I was out of town and found that it's impossible to send plain
 text email that way!
 
  best,
  douglas
 
 
 
 
  On 11/11/13 12:16 PM, douglas repetto wrote:
 
  Hi Dave,
 
  I have the list set to convert HTML mail to plain text. So it's a
 good sign that the email went through. I'm composing this in red text and
 changing fonts around. That should all disappear when this message
 arrives...
 
  Here's a list:
 
  1. * taco
  2. * truck
 
 
 
  Wheee!
 
 
 
 
  --
  ... 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
 
 
  --
  ... 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

2013-11-11 Thread Nigel Redmon
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 a...@cytomic.com wrote:

 On 11 November 2013 08:09, robert bristow-johnson
 r...@audioimagination.com wrote:
 On 11/8/13 6:47 PM, Andrew Simper wrote:
 
 On 9 November 2013 08:57, Tom Duffytdu...@tascam.com  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
 f0Fs, even floating point doesn't help.  all of the information concerning
 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