Re: [music-dsp] Implicit integration is an important term, ZDF is not
but aren't all the direct forms (even the transposed > ones), so called "delay free" >> > > i don't consider them "delay free" in their feedback path. not at all. > > Hi Robert, I think here we are not talking about "does the implementation use delays in its own feedback path" clearly a DF1 does, as does any digital filter, they have to store some state. The question is does a DF1 model the LTI continuous biquad using an implicit integration scheme? Clearly the answer is yes, it uses the bi-linear transform, which is implicit, so relies on the current and previous "state" to solve things. > >- gathering this from the top of my >> head, as i haven't look at the flow graphs much since the last time i >> tried making them into code? >> > > the semantic i used for "zero delay feedback" is that there is no delay in > the feedback loop. using the language similar to > http://www.nireaktor.com/reaktor-tutorials/zero-delay- > feedback-filters-in-reaktor/ , > > a causal discrete-time operation: > >y[n] = g(y[n-1], y[n-2], ... x[n], x[n-1],...) > > so the output sample is a function of the present input and past input > samples and of past output samples. no logical problem here. all of these > arguments of g() are known at time n. > > the "zero-delay feedback filter" purports to implement > >y[n] = g(y[n], y[n-1], y[n-2], ... x[n], x[n-1],...) > > and, of course, the logical problem is how does the algorithm g() know > what the argument y[n] is when that is precisely the value that g() is > returning? not yet determined. > > i know (especially for LTI systems), that you can plug all those arguments > into g() and solve for y[n] and get an answer. for more complicated algs, > you might have to iteratively solve for y[n]. but that does not change the > fact that, in reality, y[n] is being determined from knowledge of present > and past input samples x[n], and *past* samples of y[n]. Yes, this is the definition of implicit and if you read the title this is the clarification I'm trying to make, so thankyou for backing me up that this is the case. > that is my only bone to pick with "0df". i just see it as "another causal > algorithm" and each and every *causal* discrete-time algorithm, linear or > not, time-invariant or not, *must* define its output sample in terms of > present and past input samples and *past* output samples. This is part of the problem that causes confusion (but not even one that I have brought up!). What Urs and others are talking about is not that you need some previous state, you obviously do for a filter to work at all, but rather do you use the only the previous state, or both the current and previous state to work out the current answer. This is why I am suggesting using the standard terminology of explicit and implicit integration since it is a well defined and widely used term in mathematics and so won't cause confusion. Thanks for being confused about the terminology and so showing that even an expert in the field finds ZDF a confusing term! > like Euler's backward method (i think we called it "predictor-corrector") > for numerically solving differential equations, it's just fine to jump > through some hoops to predict the present output sample before you actually > compute it. but when you finally commit to your output sample y[n], that > value is a function of the present and past x[n] and only the *past* y[n]. > > -- > > r b-j r...@audioimagination.com > > "Imagination is more important than knowledge." Backwards Euler is an implicit method, predictor corrector is another thing again entirely. If anyone wants to discuss such methods can you please do so in another thread, people are confused enough as it is! 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] Implicit integration is an important term, ZDF is not
> If you are not familiar with what finite difference methods can do then... > This reads badly. I don't mean you Max, I meant "for anyone not familiar... " -- 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] Implicit integration is an important term, ZDF is not
Hi Max, Thanks for pointing out the term Finite differencing and the associated initial value problems, I have not been game to even bring it up, it has been difficult enough as it is without taking that further step! It is a more general formulation again than any circuit analysis methods that have discussed here as it also models the physical form of objects (eg distance, shape, density) as well as time varying behaviour when numerically integrating the possibly non-linear systems: http://en.wikipedia.org/wiki/Finite_difference If you are not familiar with what finite difference methods can do then I highly recommend having a listen to the wonderful Gilbert Strang give his lectures on Computation Mathematics, which is also available via the educational video section of iTunes as well as directly from MIT here: http://ocw.mit.edu/courses/mathematics/18-085-computational-science-and-engineering-i-fall-2008/video-lectures/ He has some examples of how solving circuits fits into this broader framework. 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] Implicit integration is an important term, ZDF is not
> There you go. It's sad that some blurtards have caused confusion with > stupid terminology - I'm talking about the zero delay filter misnomer. That > however doesn't make it seem less arrogant to make fun of people who > practice "eliminating the unit delay" as their method. Because for those > and their point of view, zero delay feedback is relevant. > > - Urs > > Hi Urs, Please don't take this thread as a personal attack, you're a friend and a peer who makes excellent music software, software that I am happy to use in my own productions. I understand that from your perspective it makes perfect sense to use the phrase "zero delay feedback filter", I am not making fun of you, I am pointing out the problems with the terminology. There is a difference between being arrogant and being deliberately confrontational to stir the pot and provoke a reaction and hopefully help people in the long run. I don't for one second think I'm better than anyone, and I'm doing my best to use references and back up my reasoning with examples, and to show the substantial existing body of knowledge that lots of people have ignored. I am not pretending I invented this stuff (that would be arrogant) I never insulted anyone even if they insult me, but if people take my technical comments personally then perhaps it is just because I am pointing out something they need to come to terms with. 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] Implicit integration is an important term, ZDF is not
> > The question seems to be arriving at: if we oughtn't keep the > potentially misleading phrase that's in common usage, and instead use > existing, more common EE parlance, what phrasing should be used? > Direct implicit integration covers it perfectly. Direct meaning not through the laplace space or other intermediate LTI analysis, and the implicit integration covers you are taking into account the the current state is used to solve for the output. You could specify the integrator being used if you don't like implicit and say "direct trapezoidal integration" or even drop the integration and specify the structure directly as in "direct trapezoidal svf". Since you specify the structure then you could possibly even shorten this further to "trapezoidal svf". > > Urs is right that mentioning "implicit integration" is so obscure as to be > useless. The word "implicit" is also technical and has too simple a > common-language connotation. > I'm sorry that you and your customers are not familiar with the correct terminology to describe this. I feel its best not to even bother to describe it in a technical manner to customers. The problem is you can come up with an explicit solution that takes great care to come out with a trapezoidal frequency response and then you can oversample this to push any inaccuracies out of the audible area, so then what? Should this be orphaned as not being "implicit" when it will sound identical and offer lower cpu to boot? Can't people just be happy that the developer has taken care to solve things as properly as they see fit with whatever methods are appropriate for the situation at hand? > Andy, can you comment on the following observation? > - the Stilson and smith model, with the artificial delay in the feedback, > which is resolved by your implicit methods is, in fact, not an explicit > method, but simply a fudged approximation; an explicit method solution > would have the correct transfer function, while the Stilson and smith does > not. > > Is that correct? > Not really. And slow down there skipper! These are not my methods, implicit integration has been around for a very long time. You are confusing implicit with trapezoidal here. The trapezoidal response is a very specific and useful one for audio. Not all implicit methods preserve resonance, eg Backwards Euler, Implicit Gear. Qucs to the rescue! http://qucs.sourceforge.net/tech/node24.html In summary an explicit method depends only on the previous state of the system to solve the system. So in that regard most music dsp people are using semi-explicit systems. Here ya go (please note that the following isn't strictly accurate since I am trying to show dependencies not specific implementations details of implicit and explicit numerical integration schemes, so just keep and eye on the "z" terms) v1z = v1 z^-1 v2z = v2 z^-1 v3z = v3 z^-1 v4z = v4 z^-1 CASCADE explicit (uses only previous outputs): v1 = v1z + g (v0 - v1z - k v4z) v2 = v2z + g (v1z - v2z) v3 = v3z + g (v2z - v3z) v4 = v4z + g (v3z - v4z) explicit (partly forward euler, the resonance and low pass filters are still explicit, but you take the current estimated output of the previous stage as the input to the next stage) - note that in the Stilton and Smith version they use (a)*vi + (1-a)*viz as the input to the i+1st stage which is an adjustment to trapezoidal integration to not cause quite as much phase delay at cutoff: v1 = v1z + g (v0 - v1z - k v4z) v2 = v2z + g (v1 - v2z) v3 = v3z + g (v2 - v3z) v4 = v4z + g (v3 - v4z) implicit: v1 = v1z + g (v0 - v1 - k v4) v2 = v2z + g (v1 - v2) v3 = v3z + g (v2 - v3) v4 = v4z + g (v3 - v4) SVF Similarly for the SVF, the fully explicit filter is: v1 = v1z + g (v0 - k v1z - v2z) v2 = v2z + g (v1z) the Chamberlin is: v1 = v1z + g (v0 - k v1z - v2z) v2 = v2z + g (v1) and the implicit: v1 = v1z + g (v0 - k v1 - v2) v2 = v2z + g (v1) I hope that helps! 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] Implicit integration is an important term, ZDF is not
> I may have misread, but the discussion seems to suggest that this > discipline is just discovering implicit finite differencing! Is that > really the case? If so, that would be odd, because implicit methods > have been around for a very long time in numerical analysis. > > Max > > Max, can I please give you a hug? I am beating my head against the wall with these music-dsp that think this stuff is somehow novel.. 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] Implicit integration is an important term, ZDF is not
On 11/13/13 1:05 PM, Lubomir I. Ivanov wrote: On 13 November 2013 08:50, Andrew Simper wrote: Now for all those people scratching their heads of the whole Zero Delay Feedback, here is the deal: Any implicit integration method applied to numerically integrate something is by its very definition using Zero Delay Feedback, linear or non-linear this is the case. You can completely ignore that you need some previous state to add things to, this is always the case for numerical integration. ... I hope this clears things up and exposes ZDF as a confusing and pointless marketing catch phrase. on topic i guess, i think that ZDF is a horrible term targeting real EE's. for the DSP crowd it may sound sane, but even then it could be expanded to something like "zero unit delay feedback" and i'm not even sure that will work any better. BTW Andy, you mention DFI a lot, perhaps because RBJ has them in the popular filters, listen, the Cookbook is really just about determining coefficients for 2nd-order IIR filters. it *does* make use of DF1 as an example of implementation. but it is meant to be agnostic about DF1 vs. Lattice vs. Chamberlin SVF or whatever. all of these different forms can be related to each other, so you can still use the Cookbook for your fav 2nd-order IIR topology and get the same frequency response. but aren't all the direct forms (even the transposed ones), so called "delay free" i don't consider them "delay free" in their feedback path. not at all. - gathering this from the top of my head, as i haven't look at the flow graphs much since the last time i tried making them into code? the semantic i used for "zero delay feedback" is that there is no delay in the feedback loop. using the language similar to http://www.nireaktor.com/reaktor-tutorials/zero-delay-feedback-filters-in-reaktor/ , a causal discrete-time operation: y[n] = g(y[n-1], y[n-2], ... x[n], x[n-1],...) so the output sample is a function of the present input and past input samples and of past output samples. no logical problem here. all of these arguments of g() are known at time n. the "zero-delay feedback filter" purports to implement y[n] = g(y[n], y[n-1], y[n-2], ... x[n], x[n-1],...) and, of course, the logical problem is how does the algorithm g() know what the argument y[n] is when that is precisely the value that g() is returning? not yet determined. i know (especially for LTI systems), that you can plug all those arguments into g() and solve for y[n] and get an answer. for more complicated algs, you might have to iteratively solve for y[n]. but that does not change the fact that, in reality, y[n] is being determined from knowledge of present and past input samples x[n], and *past* samples of y[n]. that is my only bone to pick with "0df". i just see it as "another causal algorithm" and each and every *causal* discrete-time algorithm, linear or not, time-invariant or not, *must* define its output sample in terms of present and past input samples and *past* output samples. like Euler's backward method (i think we called it "predictor-corrector") for numerically solving differential equations, it's just fine to jump through some hoops to predict the present output sample before you actually compute it. but when you finally commit to your output sample y[n], that value is a function of the present and past x[n] and only the *past* y[n]. -- 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] R: R: Implicit integration is an important term, ZDF is not
Hi Marco Thanks - sounds intriguing although I don't really follow your argument. So, to simplify, let us consider this ODE: dy/dt=-y^2 If you can build a circuit using your component examples, then you would have non-uniqueness with the backward Euler method. Or, are you effectively saying that you can't possibly build such a circuit out of the components you mention? Max On 14 November 2013 20:20, Marco Lo Monaco wrote: > Hi Max, > you need to convert your nonlinear system into a state space model with some > addiction for dealing non-linearity, reaching a set of 6 matrixes instead of > the 4 usual ones (see Yeh's PHD thesis for a good starting point). > Once you use an implicit integration scheme (like bilinear) you will always > reach (after all the calculations) to a non linear system of eqs in the form > of y - Fnl(Ky + p) = 0 where p is an historical contribute(=memory) of the > system known at time n. You will have to solve in some way (typically Newton > Raphson) that nonlinear system. > Given the type of Fnl in normal audio circuits (diodes, tubes, transistor > and opamp) the uniqueness of the solution of that eq is guaranteed with the > conditions I told you, and it is a straight consequence of Dini's implicit > function (http://en.wikipedia.org/wiki/Implicit_function_theorem) theorem. > So if you let > y - Fnl(Ky + p) = G(p,y) > Since you want to solve the implicit function G(p, y) = 0, the conditions to > do this locally (around some y0) is dG/dy != 0. Given the form of G in the > multivariate case (MIMO) you will reach the condition I explained in my last > post. > Note that differentiability of Fnl is _not_ requested. What is requested is > the differentiability of dG/dy, which if met for all y implies global > explicability of G, thus only one solution is possible and unique. This > conditions is less restrictive than you could expect, in fact, for instance > it works also for simplified PWL (non differentiable) saturator > characteristic function like opamps. > I've never found in my 10 yrs experience switching capacitors audio circuits > to be modeled and with prominent nonlinearity (I only dealt with bucket > brigade analog delay lines but it’s a simplified story for them). I think > nonetheless it is possible to model switching circuits by exchanging the > state variables among different nonlinear state space representations > (samplerate is then a limit). I don’t know if it is realistic or worth to do > that, but as a matter of principle it probably should be at least possible. > > Hope this helped > > Marco > > > > -Messaggio originale- > Da: music-dsp-boun...@music.columbia.edu > [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Max Little > Inviato: giovedì 14 novembre 2013 19:07 > A: A discussion list for music-related DSP > Oggetto: Re: [music-dsp] R: Implicit integration is an important term, ZDF > is not > > Hi Marco > > I don't know, in this way you're ruling out rather simple non-invertible > nonlinearities such as the humble quadratic which can occur in 'working' > nonlinear circuits: > http://en.wikipedia.org/wiki/Van_der_Pol_equation > > The rather trivial example here shows the problem quite clearly (see > backward Euler method): > http://en.wikipedia.org/wiki/Explicit_and_implicit_methods > > Also this analysis only works if you have differentiability and there are > some rather ubiquitous, practical nonlinear circuits (switched capacitors > for example) where this doesn't hold. > > Max > > On 14 November 2013 14:52, Marco Lo Monaco wrote: >> Hi Max, >> the uniquess is granted by the Dini's theorem which is satisfied >> always in common practical analog schematic (unless you are dealing >> with some exotheric Chua's multiple DC operating points). >> >> That condition is met if >> >> det(Jnl*K-I)!=0 >> >> where Jnl is the Jacobian of the MIMO non linearity and K is the K >> matrix (see DePoli et alias). >> It's when the implicit method becomes "explicit" only locally (or >> globally) and you can break the uncomputabilty of the graph, defeating >> the instantanoues delay in z-domain. >> In all the practical case the nonlinear implicit function is >> guaranteed to be globally "explicitable". That also makes sense since >> you are modeling a physical system that is actually working and must >> have uniqueness of solution. >> >> Marco >> >> -Messaggio originale- >> Da: music-dsp-boun...@music.columbia.edu >> [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Max Little >> Inviato: giovedì 14 novembre 2013 15:14 >> A: A discussion list for music-related DSP >> Oggetto: Re: [music-dsp] Implicit integration is an important term, >> ZDF is not >> >> Thanks Ross. >> >> Good point about the practical utility of implicit FD and increasing >> computational power. There's also all the issues about uniqueness of >> implicit FDs arising from nonlinear IVPs, and then there's stability, >> convergence, weather the resulting method is essentially >>
[music-dsp] R: R: Implicit integration is an important term, ZDF is not
Hi Max, you need to convert your nonlinear system into a state space model with some addiction for dealing non-linearity, reaching a set of 6 matrixes instead of the 4 usual ones (see Yeh's PHD thesis for a good starting point). Once you use an implicit integration scheme (like bilinear) you will always reach (after all the calculations) to a non linear system of eqs in the form of y - Fnl(Ky + p) = 0 where p is an historical contribute(=memory) of the system known at time n. You will have to solve in some way (typically Newton Raphson) that nonlinear system. Given the type of Fnl in normal audio circuits (diodes, tubes, transistor and opamp) the uniqueness of the solution of that eq is guaranteed with the conditions I told you, and it is a straight consequence of Dini's implicit function (http://en.wikipedia.org/wiki/Implicit_function_theorem) theorem. So if you let y - Fnl(Ky + p) = G(p,y) Since you want to solve the implicit function G(p, y) = 0, the conditions to do this locally (around some y0) is dG/dy != 0. Given the form of G in the multivariate case (MIMO) you will reach the condition I explained in my last post. Note that differentiability of Fnl is _not_ requested. What is requested is the differentiability of dG/dy, which if met for all y implies global explicability of G, thus only one solution is possible and unique. This conditions is less restrictive than you could expect, in fact, for instance it works also for simplified PWL (non differentiable) saturator characteristic function like opamps. I've never found in my 10 yrs experience switching capacitors audio circuits to be modeled and with prominent nonlinearity (I only dealt with bucket brigade analog delay lines but its a simplified story for them). I think nonetheless it is possible to model switching circuits by exchanging the state variables among different nonlinear state space representations (samplerate is then a limit). I dont know if it is realistic or worth to do that, but as a matter of principle it probably should be at least possible. Hope this helped Marco -Messaggio originale- Da: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Max Little Inviato: giovedì 14 novembre 2013 19:07 A: A discussion list for music-related DSP Oggetto: Re: [music-dsp] R: Implicit integration is an important term, ZDF is not Hi Marco I don't know, in this way you're ruling out rather simple non-invertible nonlinearities such as the humble quadratic which can occur in 'working' nonlinear circuits: http://en.wikipedia.org/wiki/Van_der_Pol_equation The rather trivial example here shows the problem quite clearly (see backward Euler method): http://en.wikipedia.org/wiki/Explicit_and_implicit_methods Also this analysis only works if you have differentiability and there are some rather ubiquitous, practical nonlinear circuits (switched capacitors for example) where this doesn't hold. Max On 14 November 2013 14:52, Marco Lo Monaco wrote: > Hi Max, > the uniquess is granted by the Dini's theorem which is satisfied > always in common practical analog schematic (unless you are dealing > with some exotheric Chua's multiple DC operating points). > > That condition is met if > > det(Jnl*K-I)!=0 > > where Jnl is the Jacobian of the MIMO non linearity and K is the K > matrix (see DePoli et alias). > It's when the implicit method becomes "explicit" only locally (or > globally) and you can break the uncomputabilty of the graph, defeating > the instantanoues delay in z-domain. > In all the practical case the nonlinear implicit function is > guaranteed to be globally "explicitable". That also makes sense since > you are modeling a physical system that is actually working and must > have uniqueness of solution. > > Marco > > -Messaggio originale- > Da: music-dsp-boun...@music.columbia.edu > [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Max Little > Inviato: giovedì 14 novembre 2013 15:14 > A: A discussion list for music-related DSP > Oggetto: Re: [music-dsp] Implicit integration is an important term, > ZDF is not > > Thanks Ross. > > Good point about the practical utility of implicit FD and increasing > computational power. There's also all the issues about uniqueness of > implicit FDs arising from nonlinear IVPs, and then there's stability, > convergence, weather the resulting method is essentially > non-oscillatory etc. I suppose there are additional issues to do with > frequency response which may be what matters most in audio DSP. > > Max > > > On 14 November 2013 14:06, Ross Bencina wrote: >> On 14/11/2013 11:41 PM, Max Little wrote: >>> >>> I may have misread, but the discussion seems to suggest that this >>> discipline is just discovering implicit finite differencing! Is that >>> really the case? If so, that would be odd, because implicit methods >>> have been around for a very long time in numerical analysis. >> >> >> Hi Max, >> >> I think you would b
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] R: Implicit integration is an important term, ZDF is not
Hi Marco I don't know, in this way you're ruling out rather simple non-invertible nonlinearities such as the humble quadratic which can occur in 'working' nonlinear circuits: http://en.wikipedia.org/wiki/Van_der_Pol_equation The rather trivial example here shows the problem quite clearly (see backward Euler method): http://en.wikipedia.org/wiki/Explicit_and_implicit_methods Also this analysis only works if you have differentiability and there are some rather ubiquitous, practical nonlinear circuits (switched capacitors for example) where this doesn't hold. Max On 14 November 2013 14:52, Marco Lo Monaco wrote: > Hi Max, > the uniquess is granted by the Dini's theorem which is satisfied always in > common practical analog schematic (unless you are dealing with some > exotheric Chua's multiple DC operating points). > > That condition is met if > > det(Jnl*K-I)!=0 > > where Jnl is the Jacobian of the MIMO non linearity and K is the K matrix > (see DePoli et alias). > It's when the implicit method becomes "explicit" only locally (or globally) > and you can break the uncomputabilty of the graph, defeating the > instantanoues delay in z-domain. > In all the practical case the nonlinear implicit function is guaranteed to > be globally "explicitable". That also makes sense since you are modeling a > physical system that is actually working and must have uniqueness of > solution. > > Marco > > -Messaggio originale- > Da: music-dsp-boun...@music.columbia.edu > [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Max Little > Inviato: giovedì 14 novembre 2013 15:14 > A: A discussion list for music-related DSP > Oggetto: Re: [music-dsp] Implicit integration is an important term, ZDF is > not > > Thanks Ross. > > Good point about the practical utility of implicit FD and increasing > computational power. There's also all the issues about uniqueness of > implicit FDs arising from nonlinear IVPs, and then there's stability, > convergence, weather the resulting method is essentially non-oscillatory > etc. I suppose there are additional issues to do with frequency response > which may be what matters most in audio DSP. > > Max > > > On 14 November 2013 14:06, Ross Bencina wrote: >> On 14/11/2013 11:41 PM, Max Little wrote: >>> >>> I may have misread, but the discussion seems to suggest that this >>> discipline is just discovering implicit finite differencing! Is that >>> really the case? If so, that would be odd, because implicit methods >>> have been around for a very long time in numerical analysis. >> >> >> Hi Max, >> >> I think you would be extrapolating too far to say that a few people >> tossing around ideas on a mailing list are representative of the >> trends of an entire discipline. On this mailing list I would struggle >> to guess which "this discipline" you are refering to. Suffice to say >> that a lot of the people discussing things in this thread are developers > not research scientists. >> >> Some practitioners are just "discovering" new practicable applications >> of implicit finite differencing in the last 10 years or so. One good >> reason for this is that in the past these techniques were completely >> irrelevant because they were too expensive to apply in real time at >> the required scale (100+ synthesizer voices, 100+ DAW channels). It >> also seems that the market has changed such that people will pay for a >> monophonic synth that burns a whole >> i7 CPU core. >> >> Cheers, >> >> 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 > > > > -- > Max Little (www.maxlittle.net) > Wellcome Trust/MIT Fellow and Assistant Professor, Aston University > TED Fellow (fellows.ted.com/profiles/max-little) > Visiting Assistant Professor, MIT > Room MB318A, Aston University > Aston Triangle, Birmingham, B4 7ET, UK > UK +44 7710 609564/+44 121 204 5327 > Skype dr.max.little > -- > 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 -- Max Little (www.maxlittle.net) Wellcome Trust/MIT Fellow and Assistant Professor, Aston University TED Fellow (fellows.ted.com/profiles/max-little) Visiting Assistant Professor, MIT Room MB318A, Aston University Aston Triangle, Birmingham, B4 7ET, UK UK +44 7710 609564/+44 121 204 5327 Skype dr.max.little -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews
[music-dsp] Using TL07X Op Amps in Analog Synthesizers webcast NOW!
Just started at 1pm NYC time: http://oreillynet.com/pub/e/2919?imm_mid=0b30f1&cmp=em-na-webcast-info-webcast_2013 -- ... 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] 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
[music-dsp] R: Implicit integration is an important term, ZDF is not
Hi Max, the uniquess is granted by the Dini's theorem which is satisfied always in common practical analog schematic (unless you are dealing with some exotheric Chua's multiple DC operating points). That condition is met if det(Jnl*K-I)!=0 where Jnl is the Jacobian of the MIMO non linearity and K is the K matrix (see DePoli et alias). It's when the implicit method becomes "explicit" only locally (or globally) and you can break the uncomputabilty of the graph, defeating the instantanoues delay in z-domain. In all the practical case the nonlinear implicit function is guaranteed to be globally "explicitable". That also makes sense since you are modeling a physical system that is actually working and must have uniqueness of solution. Marco -Messaggio originale- Da: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Max Little Inviato: giovedì 14 novembre 2013 15:14 A: A discussion list for music-related DSP Oggetto: Re: [music-dsp] Implicit integration is an important term, ZDF is not Thanks Ross. Good point about the practical utility of implicit FD and increasing computational power. There's also all the issues about uniqueness of implicit FDs arising from nonlinear IVPs, and then there's stability, convergence, weather the resulting method is essentially non-oscillatory etc. I suppose there are additional issues to do with frequency response which may be what matters most in audio DSP. Max On 14 November 2013 14:06, Ross Bencina wrote: > On 14/11/2013 11:41 PM, Max Little wrote: >> >> I may have misread, but the discussion seems to suggest that this >> discipline is just discovering implicit finite differencing! Is that >> really the case? If so, that would be odd, because implicit methods >> have been around for a very long time in numerical analysis. > > > Hi Max, > > I think you would be extrapolating too far to say that a few people > tossing around ideas on a mailing list are representative of the > trends of an entire discipline. On this mailing list I would struggle > to guess which "this discipline" you are refering to. Suffice to say > that a lot of the people discussing things in this thread are developers not research scientists. > > Some practitioners are just "discovering" new practicable applications > of implicit finite differencing in the last 10 years or so. One good > reason for this is that in the past these techniques were completely > irrelevant because they were too expensive to apply in real time at > the required scale (100+ synthesizer voices, 100+ DAW channels). It > also seems that the market has changed such that people will pay for a > monophonic synth that burns a whole > i7 CPU core. > > Cheers, > > 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 -- Max Little (www.maxlittle.net) Wellcome Trust/MIT Fellow and Assistant Professor, Aston University TED Fellow (fellows.ted.com/profiles/max-little) Visiting Assistant Professor, MIT Room MB318A, Aston University Aston Triangle, Birmingham, B4 7ET, UK UK +44 7710 609564/+44 121 204 5327 Skype dr.max.little -- 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 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] Implicit integration is an important term, ZDF is not
Hi Ross Thanks for the link to that book. I remember that Stefan did some great work in energy-preserving FD methods for musical instrument simulation when he was working with J.O. Smith at CCRMA, trying to extend the waveguide method really. These are quite specialized though, and won't apply to an arbitrary nonlinear electronic circuit - there has to be an underlying 'conservation law'. Shame that there aren't more of these kind of systematic texts on numerical analysis applied to musical electronics. Max On 14 November 2013 14:23, Ross Bencina wrote: > Hi Max, > > Another data point which would seem to support your take on things. This is > the first monograph in Sound Synthesis that I'm aware of that specifically > addresses finite difference methods (other examples welcome): > > Stefan Bilbao (2009), "Numerical Sound Synthesis: Finite Difference Schemes > and Simulation in Musical Acoustics" > > http://www.amazon.com/Numerical-Sound-Synthesis-Difference-Simulation/dp/0470510463 > > Not that there are that many books on sound synthesis... > > Ross. > > > > On 15/11/2013 1:14 AM, Max Little wrote: >> >> Thanks Ross. >> >> Good point about the practical utility of implicit FD and increasing >> computational power. There's also all the issues about uniqueness of >> implicit FDs arising from nonlinear IVPs, and then there's stability, >> convergence, weather the resulting method is essentially >> non-oscillatory etc. I suppose there are additional issues to do with >> frequency response which may be what matters most in audio DSP. >> >> Max >> >> >> On 14 November 2013 14:06, Ross Bencina >> wrote: >>> >>> On 14/11/2013 11:41 PM, Max Little wrote: I may have misread, but the discussion seems to suggest that this discipline is just discovering implicit finite differencing! Is that really the case? If so, that would be odd, because implicit methods have been around for a very long time in numerical analysis. >>> >>> >>> >>> Hi Max, >>> >>> I think you would be extrapolating too far to say that a few people >>> tossing >>> around ideas on a mailing list are representative of the trends of an >>> entire >>> discipline. On this mailing list I would struggle to guess which "this >>> discipline" you are refering to. Suffice to say that a lot of the people >>> discussing things in this thread are developers not research scientists. >>> >>> Some practitioners are just "discovering" new practicable applications of >>> implicit finite differencing in the last 10 years or so. One good reason >>> for >>> this is that in the past these techniques were completely irrelevant >>> because >>> they were too expensive to apply in real time at the required scale (100+ >>> synthesizer voices, 100+ DAW channels). It also seems that the market has >>> changed such that people will pay for a monophonic synth that burns a >>> whole >>> i7 CPU core. >>> >>> Cheers, >>> >>> 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 >> >> >> >> > -- > 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 -- Max Little (www.maxlittle.net) Wellcome Trust/MIT Fellow and Assistant Professor, Aston University TED Fellow (fellows.ted.com/profiles/max-little) Visiting Assistant Professor, MIT Room MB318A, Aston University Aston Triangle, Birmingham, B4 7ET, UK UK +44 7710 609564/+44 121 204 5327 Skype dr.max.little -- 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] Implicit integration is an important term, ZDF is not
Hi > Sorry if this is over clarification, but the "zero"-ed delay is the > artificial one in the feedback path. > This whole thing is about cheating vs doing it right. ... >> The cheating isn't exactly explicit fd. It's just an > incorrect approximation that's very common. > > My understanding of this thread is that no-one has made direct comparison > between implicit and explicit methods, but andy loosely (erroneously?) > lumped the S&S approximation in with explicit methods in a vague hand wavy > way. > In my last post, I called on him to confirm that exact assertion. > The S&S -is- predicated on an explicit method... But it's also incorrect. > So implicit is not better than explicit because of reasons, but a working > implicit is better than a broken explicit. That's as far as it goes. ... I think I was just following Urs' description about conflating 'zero delay' with implicit FD. My only contribution here was really just a simple comment that implicit FD doesn't somehow magically eliminate delays. >> I imagine so! I get the impression that scant few in this field have an > applied maths background. Plenty of EE, some compsci, and the occasional > pure mathematician. I'd like to claim that applied maths leaves one with a > gritty realism and unshakeable pragmatism. ;) Thanks! Yes, you do get to realize that maths is only a rather hollow imitation of reality ... As Ross says, I wouldn't try to generalize too far about contributors to this thread and the 'field' in itself, whatever that means! Cheers Max -- 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] Implicit integration is an important term, ZDF is not
Hi Max, Another data point which would seem to support your take on things. This is the first monograph in Sound Synthesis that I'm aware of that specifically addresses finite difference methods (other examples welcome): Stefan Bilbao (2009), "Numerical Sound Synthesis: Finite Difference Schemes and Simulation in Musical Acoustics" http://www.amazon.com/Numerical-Sound-Synthesis-Difference-Simulation/dp/0470510463 Not that there are that many books on sound synthesis... Ross. On 15/11/2013 1:14 AM, Max Little wrote: Thanks Ross. Good point about the practical utility of implicit FD and increasing computational power. There's also all the issues about uniqueness of implicit FDs arising from nonlinear IVPs, and then there's stability, convergence, weather the resulting method is essentially non-oscillatory etc. I suppose there are additional issues to do with frequency response which may be what matters most in audio DSP. Max On 14 November 2013 14:06, Ross Bencina wrote: On 14/11/2013 11:41 PM, Max Little wrote: I may have misread, but the discussion seems to suggest that this discipline is just discovering implicit finite differencing! Is that really the case? If so, that would be odd, because implicit methods have been around for a very long time in numerical analysis. Hi Max, I think you would be extrapolating too far to say that a few people tossing around ideas on a mailing list are representative of the trends of an entire discipline. On this mailing list I would struggle to guess which "this discipline" you are refering to. Suffice to say that a lot of the people discussing things in this thread are developers not research scientists. Some practitioners are just "discovering" new practicable applications of implicit finite differencing in the last 10 years or so. One good reason for this is that in the past these techniques were completely irrelevant because they were too expensive to apply in real time at the required scale (100+ synthesizer voices, 100+ DAW channels). It also seems that the market has changed such that people will pay for a monophonic synth that burns a whole i7 CPU core. Cheers, 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 -- 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] Implicit integration is an important term, ZDF is not
Heya, On Thursday, November 14, 2013, Max Little wrote: > Hi Dave > > > Oh, that's really not the question. If you insert a delay that isn't > there > > into the feedback path of a filter, you get the wrong transfer function. > > No-one has been adding in random delays into linear filters, because > you'd > > hear that immediately and it just means your response is wrong. On the > > other hand, in a synth filter feedback path, that delay doesn't destroy > the > > response for low feedback amounts, but as you turn it up, you deviate > from > > the response you wanted. > > Hmmm ... yes, well I wasn't making any statements at all about > inserting random delays, obviously, doing that would produce some > 'unintended' consequences as you suggest! I was restricting my > comments to the implicit FD vs. 'zero delay' confusion. > Sorry if this is over clarification, but the "zero"-ed delay is the artificial one in the feedback path. This whole thing is about cheating vs doing it right. > >> Nah, this is about the Stilson and smith models, and their ilk. The old > > tendency for people to go: oh, feedback, meh, I'll just stick a delay in > > that and that'll be fine. That's stopping now. > > Should clarify, I was just responding to Urs' saying that the implicit > FD method he's using sounds better than (I'm inferring) explicit FD. > > The cheating isn't exactly explicit fd. It's just an incorrect approximation that's very common. My understanding of this thread is that no-one has made direct comparison between implicit and explicit methods, but andy loosely (erroneously?) lumped the S&S approximation in with explicit methods in a vague hand wavy way. In my last post, I called on him to confirm that exact assertion. The S&S -is- predicated on an explicit method... But it's also incorrect. So implicit is not better than explicit because of reasons, but a working implicit is better than a broken explicit. That's as far as it goes. > > Interesting topic, a nice diversion from me trying to track down the > >> source of a missing scale factor of 2 in some E-M PCA code I'm > >> writing, aargh! > >> > >> Woo! You're, like, a real numerical analyst! Yaay! Pleasure to make your > > acquaintance! > > Nice to talk to you too! Well, I'm a professional applied > mathematician, wouldn't say I'm a 'numerical analyst' per se, although > I have a PhD from Oxford in applied mathematics (nonlinear dynamics > and nonlinear DSP), and have about 15 year's experience of numerical > analysis, nonlinear IVP's included. So, I think I have learned a thing > or two about the subject ... > > I imagine so! I get the impression that scant few in this field have an applied maths background. Plenty of EE, some compsci, and the occasional pure mathematician. I'd like to claim that applied maths leaves one with a gritty realism and unshakeable pragmatism. ;) All the best, Dave. > Max > > -- > Max Little (www.maxlittle.net) > Wellcome Trust/MIT Fellow and Assistant Professor, Aston University > TED Fellow (fellows.ted.com/profiles/max-little) > Visiting Assistant Professor, MIT > Room MB318A, Aston University > Aston Triangle, Birmingham, B4 7ET, UK > UK +44 7710 609564/+44 121 204 5327 > Skype dr.max.little > -- > 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] Implicit integration is an important term, ZDF is not
Thanks Ross. Good point about the practical utility of implicit FD and increasing computational power. There's also all the issues about uniqueness of implicit FDs arising from nonlinear IVPs, and then there's stability, convergence, weather the resulting method is essentially non-oscillatory etc. I suppose there are additional issues to do with frequency response which may be what matters most in audio DSP. Max On 14 November 2013 14:06, Ross Bencina wrote: > On 14/11/2013 11:41 PM, Max Little wrote: >> >> I may have misread, but the discussion seems to suggest that this >> discipline is just discovering implicit finite differencing! Is that >> really the case? If so, that would be odd, because implicit methods >> have been around for a very long time in numerical analysis. > > > Hi Max, > > I think you would be extrapolating too far to say that a few people tossing > around ideas on a mailing list are representative of the trends of an entire > discipline. On this mailing list I would struggle to guess which "this > discipline" you are refering to. Suffice to say that a lot of the people > discussing things in this thread are developers not research scientists. > > Some practitioners are just "discovering" new practicable applications of > implicit finite differencing in the last 10 years or so. One good reason for > this is that in the past these techniques were completely irrelevant because > they were too expensive to apply in real time at the required scale (100+ > synthesizer voices, 100+ DAW channels). It also seems that the market has > changed such that people will pay for a monophonic synth that burns a whole > i7 CPU core. > > Cheers, > > 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 -- Max Little (www.maxlittle.net) Wellcome Trust/MIT Fellow and Assistant Professor, Aston University TED Fellow (fellows.ted.com/profiles/max-little) Visiting Assistant Professor, MIT Room MB318A, Aston University Aston Triangle, Birmingham, B4 7ET, UK UK +44 7710 609564/+44 121 204 5327 Skype dr.max.little -- 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] Implicit integration is an important term, ZDF is not
On 14/11/2013 11:41 PM, Max Little wrote: I may have misread, but the discussion seems to suggest that this discipline is just discovering implicit finite differencing! Is that really the case? If so, that would be odd, because implicit methods have been around for a very long time in numerical analysis. Hi Max, I think you would be extrapolating too far to say that a few people tossing around ideas on a mailing list are representative of the trends of an entire discipline. On this mailing list I would struggle to guess which "this discipline" you are refering to. Suffice to say that a lot of the people discussing things in this thread are developers not research scientists. Some practitioners are just "discovering" new practicable applications of implicit finite differencing in the last 10 years or so. One good reason for this is that in the past these techniques were completely irrelevant because they were too expensive to apply in real time at the required scale (100+ synthesizer voices, 100+ DAW channels). It also seems that the market has changed such that people will pay for a monophonic synth that burns a whole i7 CPU core. Cheers, 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 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] Implicit integration is an important term, ZDF is not
Hi Dave > Oh, that's really not the question. If you insert a delay that isn't there > into the feedback path of a filter, you get the wrong transfer function. > No-one has been adding in random delays into linear filters, because you'd > hear that immediately and it just means your response is wrong. On the > other hand, in a synth filter feedback path, that delay doesn't destroy the > response for low feedback amounts, but as you turn it up, you deviate from > the response you wanted. Hmmm ... yes, well I wasn't making any statements at all about inserting random delays, obviously, doing that would produce some 'unintended' consequences as you suggest! I was restricting my comments to the implicit FD vs. 'zero delay' confusion. >> Nah, this is about the Stilson and smith models, and their ilk. The old > tendency for people to go: oh, feedback, meh, I'll just stick a delay in > that and that'll be fine. That's stopping now. Should clarify, I was just responding to Urs' saying that the implicit FD method he's using sounds better than (I'm inferring) explicit FD. > Interesting topic, a nice diversion from me trying to track down the >> source of a missing scale factor of 2 in some E-M PCA code I'm >> writing, aargh! >> >> Woo! You're, like, a real numerical analyst! Yaay! Pleasure to make your > acquaintance! Nice to talk to you too! Well, I'm a professional applied mathematician, wouldn't say I'm a 'numerical analyst' per se, although I have a PhD from Oxford in applied mathematics (nonlinear dynamics and nonlinear DSP), and have about 15 year's experience of numerical analysis, nonlinear IVP's included. So, I think I have learned a thing or two about the subject ... Max -- Max Little (www.maxlittle.net) Wellcome Trust/MIT Fellow and Assistant Professor, Aston University TED Fellow (fellows.ted.com/profiles/max-little) Visiting Assistant Professor, MIT Room MB318A, Aston University Aston Triangle, Birmingham, B4 7ET, UK UK +44 7710 609564/+44 121 204 5327 Skype dr.max.little -- 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] Implicit integration is an important term, ZDF is not
Heya, On Thursday, November 14, 2013, Max Little wrote: > > Anway, I didn't know that implicit finite differencing in audio signal > processing led to better sounding outputs, would like to hear a demo > of this and test out whether my ears can tell the difference, > 'blinded' of course. Oh, that's really not the question. If you insert a delay that isn't there into the feedback path of a filter, you get the wrong transfer function. No-one has been adding in random delays into linear filters, because you'd hear that immediately and it just means your response is wrong. On the other hand, in a synth filter feedback path, that delay doesn't destroy the response for low feedback amounts, but as you turn it up, you deviate from the response you wanted. So, broken system and fixed system sound the same when the feedback is at zero (low resonance), but as you crank it, the broken system sounds broken, and the fixed system sounds like the analogue gear. > But of course, that isn't maths, it is > pscyhoacoustics, and that is a whole different thing, where you can't > prove anything for sure and subjectivity and suggestion effects runs > rife (different coloured speaker cables ... recently, I saw a company > selling metal 'bricks' that you were supposed to place on your > amplifier to make it sound better). > > Nah, this is about the Stilson and smith models, and their ilk. The old tendency for people to go: oh, feedback, meh, I'll just stick a delay in that and that'll be fine. That's stopping now. Interesting topic, a nice diversion from me trying to track down the > source of a missing scale factor of 2 in some E-M PCA code I'm > writing, aargh! > > Woo! You're, like, a real numerical analyst! Yaay! Pleasure to make your acquaintance! Dave. > Max > > > > On 14 November 2013 12:48, Urs Heckmann wrote: > > To some extent, yes. > > > > While the terminology was coined earlier, two years ago we released a > software that uses the very same filter algorithm in both ways: The > feedback loop of the analogue counterpart was either realised with a unit > delay or it was made instantaneous aka zero-delay-feedback with an > iterative solver. We then used the term zero delay feedback filters in our > marketing to point out the difference between those two methods. Because > really, that was the only difference in the actual code. Yet, the sound of > the filters rendered with zero delay feedback is remarkably better - if one > knows what to listen for. > > > > We can thus claim, and still do, that with same placement of > non-linearities, literally same code, zero delay feedback filters have > advantages over those using a unit delay. It's quite simple, really, and > meant quite literally so. It has nothing to do with the way any analogue > filter was analysed and recreated in code. > > > > The product in question has been received very well in the music > community. This led to an inflationary use of the word zero delay feedback > filters in marketing, up to the point where (desperate?) people who had no > idea what it meant used the word in a confusing fashion: Suddenly some > manufacturers of competing products would cough up the term "zero delay > filter", which wasn't meant as a joke, but was just plain idiotism. It put > the terminology itself into questionably territory. > > > > So what's happening here is, a term that - for us and maybe others too - > is perfectly relevant and which builds an integral part of our generally > modest marketing strategy, is being slammed in a most unfortunate way. > > > > That said, I have a good laugh at many puzzling marketing campaigns out > there, but I wouldn't go and talk them down. It's just not good style. > > > > - Urs > > > > On 14.11.2013, at 12:31, Max Little wrote: > > > >> I've been following this somewhat heated discussion for a while! I've > >> not read the appropriate literature, but does this really just revolve > >> around whether someone uses implicit versus explicit finite difference > >> methods for nonlinear ODE models of analog circuits? > >> > >> Max > >> > >> > >> On 14 November 2013 11:26, Urs Heckmann wrote: > >>> My point is, > >>> > >>> It's not the fault of those who use the term in a correct way that > some others have used it in a confusing way. > >>> > >>> That however doesn't justify a general - at times derogative - rant > against using the term. I don't think it's very clever either. > >>> > >>> I'll leave it at that. > >>> > >>> - Urs > >>> > >>> On 14.11.2013, at 12:06, Dave Gamble wrote: > >>> > Hey Urs, > > Not quite sure if this was aimed at me or Andy, though it doesn't > make a > ton of sense with either. > > Just in case it was aimed at me, I've never ever denied the utility of > Andy&Vadim's work; quite the opposite. > I'm not sure I've even ranted about the phrase. Just documented its > history > and explained how it caused confusion. > > Dave. > > On Thursda
[music-dsp] Implicit integration is an important term, ZDF is not
On Thursday, November 14, 2013, Urs Heckmann wrote: > > On 14.11.2013, at 13:20, Dave Gamble wrote: > > > The "zero delay filters" name is meaningful to those already expert in > the > > field, but less so for newcomers who won't be aware of exactly which > delay > > it is that's been obviated. And the point Andy makes when starting this > > thread is that the results in this nascent field are far more broad than > > are captured or described by the phrase "zero delay filter". > > wrong term :-p Huh. I see it abbreviated to 0df everywhere. I stand corrected. I can see how this might feel like an attack on you now. Not my intention. I'm much more interested in the academic side, and understanding Andy's humour :P So zero delay feedback filter is an abbreviation for "no unit delay artificially inserted into the feedback path of the filter", which exactly marries with what I had inferred from the history. Originally, Vadim's work could be said to be about "eliminating feedback path delays" (which rings a bell), and, sorry if this is hand wavy, Andy's work generalises the idea to direct discretisation via implicit methods (which would never lead to inserting an arbitrary delay into the feedback path). Urs, I can see how your description is exact, but also how it's context creates a specificity that can confuse. I was confused. 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 > -- 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] Implicit integration is an important term, ZDF is not
Thanks Urs. Politely, since your explanation is riddled with 'zero delay', you are at the risk of generating endless sources of confusion, for example, by contrasting 'zero delay' with 'unit delay'. Anway, I didn't know that implicit finite differencing in audio signal processing led to better sounding outputs, would like to hear a demo of this and test out whether my ears can tell the difference, 'blinded' of course. But of course, that isn't maths, it is pscyhoacoustics, and that is a whole different thing, where you can't prove anything for sure and subjectivity and suggestion effects runs rife (different coloured speaker cables ... recently, I saw a company selling metal 'bricks' that you were supposed to place on your amplifier to make it sound better). Interesting topic, a nice diversion from me trying to track down the source of a missing scale factor of 2 in some E-M PCA code I'm writing, aargh! Max On 14 November 2013 12:48, Urs Heckmann wrote: > To some extent, yes. > > While the terminology was coined earlier, two years ago we released a > software that uses the very same filter algorithm in both ways: The feedback > loop of the analogue counterpart was either realised with a unit delay or it > was made instantaneous aka zero-delay-feedback with an iterative solver. We > then used the term zero delay feedback filters in our marketing to point out > the difference between those two methods. Because really, that was the only > difference in the actual code. Yet, the sound of the filters rendered with > zero delay feedback is remarkably better - if one knows what to listen for. > > We can thus claim, and still do, that with same placement of non-linearities, > literally same code, zero delay feedback filters have advantages over those > using a unit delay. It's quite simple, really, and meant quite literally so. > It has nothing to do with the way any analogue filter was analysed and > recreated in code. > > The product in question has been received very well in the music community. > This led to an inflationary use of the word zero delay feedback filters in > marketing, up to the point where (desperate?) people who had no idea what it > meant used the word in a confusing fashion: Suddenly some manufacturers of > competing products would cough up the term "zero delay filter", which wasn't > meant as a joke, but was just plain idiotism. It put the terminology itself > into questionably territory. > > So what's happening here is, a term that - for us and maybe others too - is > perfectly relevant and which builds an integral part of our generally modest > marketing strategy, is being slammed in a most unfortunate way. > > That said, I have a good laugh at many puzzling marketing campaigns out > there, but I wouldn't go and talk them down. It's just not good style. > > - Urs > > On 14.11.2013, at 12:31, Max Little wrote: > >> I've been following this somewhat heated discussion for a while! I've >> not read the appropriate literature, but does this really just revolve >> around whether someone uses implicit versus explicit finite difference >> methods for nonlinear ODE models of analog circuits? >> >> Max >> >> >> On 14 November 2013 11:26, Urs Heckmann wrote: >>> My point is, >>> >>> It's not the fault of those who use the term in a correct way that some >>> others have used it in a confusing way. >>> >>> That however doesn't justify a general - at times derogative - rant against >>> using the term. I don't think it's very clever either. >>> >>> I'll leave it at that. >>> >>> - Urs >>> >>> On 14.11.2013, at 12:06, Dave Gamble wrote: >>> Hey Urs, Not quite sure if this was aimed at me or Andy, though it doesn't make a ton of sense with either. Just in case it was aimed at me, I've never ever denied the utility of Andy&Vadim's work; quite the opposite. I'm not sure I've even ranted about the phrase. Just documented its history and explained how it caused confusion. Dave. On Thursday, November 14, 2013, Urs Heckmann wrote: > Hehehe, > > Our methods of filter design, which are created merely from the viewpoint > of algorithm design than from the perspective of "conformity with EE > terms" > is all about eliminating the unit delay - or using it as performance > optimisation. > > I respect your viewpoint, but quite honestly, you're not doing anyone a > favour if you deny the usefulness of "eliminating the unit delay in > typical > dsp implementations of analogue filter topologies". > > You use DF filters to base your rant about the terminology, when quite > clearly the filters that people refer to as having a unit delay in the > feedback path are different ones, such as Stilson/Smith's proposed Moog > ladder implementation or Chamberlin's SVF. > > As much irony as there may be in the fact that DF filters are *transformed > imp
Re: [music-dsp] Implicit integration is an important term, ZDF is not
OK, thanks Dave, I understand now. I would say that, 'zero delay' is just technically wrong, whereas 'implicit integration' is a rather obscure technical term which has origins in numerical analysis. However, it seems that 'implicit finite differencing' is what is actually being used, why not call a spade a spade? Well, at least this might also hint at the fact that there are a plethora of ways other than finite differencing which could use in attempting to solve nonlinear initial value ODE problems like this - for example, one could do a time window of finite element and then sample from that. Might even sound better than implicit finite differencing, who knows! Just throwing some ideas out there. Max On 14 November 2013 12:54, Dave Gamble wrote: > Hi, > > On Thursday, November 14, 2013, Max Little wrote: > >> Thanks Dave. >> >> If that's really the case, then the phrase 'zero delay filter' is very >> misleading, because it seems to imply that there is no relationship >> between samples in time which clearly cannot be the case (otherwise, >> e.g. oscillation would be impossible for the continuous-state >> dynamical systems we are dealing with here - it is a simple argument >> to show that you need a state-space of at least two dimensions to >> allow oscillation). Just because one cannot rearrange the finite >> difference system to isolate the next time sample to be computed on >> the left hand side of an equation, doesn't mean that the time samples >> are not functionally related. >> >> > That was my original misreading too. I made this same argument in the > technical thread, along with some archeology as to how the term might have > come I to usage in the field. > > >> I may have misread, but the discussion seems to suggest that this >> discipline is just discovering implicit finite differencing! Is that >> really the case? If so, that would be odd, because implicit methods >> have been around for a very long time in numerical analysis. >> >> Far from it! What is happening is that a few list contributors have > been putting worked examples of very high quality into the public domain, > and we are debating presentation. I believe Andy is on our side of the > debate regarding phrasing now. > > The question seems to be arriving at: if we oughtn't keep the > potentially misleading phrase that's in common usage, and instead use > existing, more common EE parlance, what phrasing should be used? > > Urs is right that mentioning "implicit integration" is so obscure as to be > useless. The word "implicit" is also technical and has too simple a > common-language connotation. > > I'll venture an idea, not because I have great faith in it, but because I > feel like I ought to contribute something more than just narrative. Perhaps > "temporally coherent" or something of that form could accurately capture > the difference between a system that 'cheats' by inserting delays where > there are none, and one that is working correctly. > > Andy, can you comment on the following observation? > - the Stilson and smith model, with the artificial delay in the feedback, > which is resolved by your implicit methods is, in fact, not an explicit > method, but simply a fudged approximation; an explicit method solution > would have the correct transfer function, while the Stilson and smith does > not. > > Is that correct? > > > Dave. > > > >> Max >> >> >> >> >> On 14 November 2013 12:20, Dave Gamble wrote: >> > Hi, >> > >> > On Thursday, November 14, 2013, Max Little wrote: >> > >> >> I've been following this somewhat heated discussion for a while! I've >> >> not read the appropriate literature, but does this really just revolve >> >> around whether someone uses implicit versus explicit finite difference >> >> methods for nonlinear ODE models of analog circuits. >> > >> > Basically, yes. >> > I have a strong suspicion that these techniques will be making their way >> > into much more common usage in audio (I think it's fair to claim that >> > they're currently only in use at the cutting edge), and into courses etc, >> > so I think it's reasonable that there's some to-ing and fro-ing about >> > terminology, especially since this stuff does come with a really >> > significant set of results (filter topologies etc). >> > The thing is, the appropriate literature is something of a gold mine, and >> > so this is something akin to a discussion of what should be written on >> the >> > placard above the entrance. >> > >> > The "zero delay filters" name is meaningful to those already expert in >> the >> > field, but less so for newcomers who won't be aware of exactly which >> delay >> > it is that's been obviated. And the point Andy makes when starting this >> > thread is that the results in this nascent field are far more broad than >> > are captured or described by the phrase "zero delay filter". >> > >> > This is the language thread that exists in parallel to the technical >> > implicit/explicit methods threads. >> > >> > Dave. >>
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] Implicit integration is an important term, ZDF is not
Hi, On Thursday, November 14, 2013, Max Little wrote: > Thanks Dave. > > If that's really the case, then the phrase 'zero delay filter' is very > misleading, because it seems to imply that there is no relationship > between samples in time which clearly cannot be the case (otherwise, > e.g. oscillation would be impossible for the continuous-state > dynamical systems we are dealing with here - it is a simple argument > to show that you need a state-space of at least two dimensions to > allow oscillation). Just because one cannot rearrange the finite > difference system to isolate the next time sample to be computed on > the left hand side of an equation, doesn't mean that the time samples > are not functionally related. > > That was my original misreading too. I made this same argument in the technical thread, along with some archeology as to how the term might have come I to usage in the field. > I may have misread, but the discussion seems to suggest that this > discipline is just discovering implicit finite differencing! Is that > really the case? If so, that would be odd, because implicit methods > have been around for a very long time in numerical analysis. > > Far from it! What is happening is that a few list contributors have been putting worked examples of very high quality into the public domain, and we are debating presentation. I believe Andy is on our side of the debate regarding phrasing now. The question seems to be arriving at: if we oughtn't keep the potentially misleading phrase that's in common usage, and instead use existing, more common EE parlance, what phrasing should be used? Urs is right that mentioning "implicit integration" is so obscure as to be useless. The word "implicit" is also technical and has too simple a common-language connotation. I'll venture an idea, not because I have great faith in it, but because I feel like I ought to contribute something more than just narrative. Perhaps "temporally coherent" or something of that form could accurately capture the difference between a system that 'cheats' by inserting delays where there are none, and one that is working correctly. Andy, can you comment on the following observation? - the Stilson and smith model, with the artificial delay in the feedback, which is resolved by your implicit methods is, in fact, not an explicit method, but simply a fudged approximation; an explicit method solution would have the correct transfer function, while the Stilson and smith does not. Is that correct? Dave. > Max > > > > > On 14 November 2013 12:20, Dave Gamble wrote: > > Hi, > > > > On Thursday, November 14, 2013, Max Little wrote: > > > >> I've been following this somewhat heated discussion for a while! I've > >> not read the appropriate literature, but does this really just revolve > >> around whether someone uses implicit versus explicit finite difference > >> methods for nonlinear ODE models of analog circuits. > > > > Basically, yes. > > I have a strong suspicion that these techniques will be making their way > > into much more common usage in audio (I think it's fair to claim that > > they're currently only in use at the cutting edge), and into courses etc, > > so I think it's reasonable that there's some to-ing and fro-ing about > > terminology, especially since this stuff does come with a really > > significant set of results (filter topologies etc). > > The thing is, the appropriate literature is something of a gold mine, and > > so this is something akin to a discussion of what should be written on > the > > placard above the entrance. > > > > The "zero delay filters" name is meaningful to those already expert in > the > > field, but less so for newcomers who won't be aware of exactly which > delay > > it is that's been obviated. And the point Andy makes when starting this > > thread is that the results in this nascent field are far more broad than > > are captured or described by the phrase "zero delay filter". > > > > This is the language thread that exists in parallel to the technical > > implicit/explicit methods threads. > > > > Dave. > > > > > > > >> > > > > > >> > > Max > >> > >> > >> On 14 November 2013 11:26, Urs Heckmann wrote: > >> > My point is, > >> > > >> > It's not the fault of those who use the term in a correct way that > some > >> others have used it in a confusing way. > >> > > >> > That however doesn't justify a general - at times derogative - rant > >> against using the term. I don't think it's very clever either. > >> > > >> > I'll leave it at that. > >> > > >> > - Urs > >> > > >> > On 14.11.2013, at 12:06, Dave Gamble wrote: > >> > > >> >> Hey Urs, > >> >> > >> >> Not quite sure if this was aimed at me or Andy, though it doesn't > make a > >> >> ton of sense with either. > >> >> > >> >> Just in case it was aimed at me, I've never ever denied the utility > of > >> >> Andy&Vadim's work; quite the opposite. > >> >> I'm not sure I've even ranted about the phrase. Just documented its > >> history >
Re: [music-dsp] Implicit integration is an important term, ZDF is not
On 14.11.2013, at 13:20, Dave Gamble wrote: > The "zero delay filters" name is meaningful to those already expert in the > field, but less so for newcomers who won't be aware of exactly which delay > it is that's been obviated. And the point Andy makes when starting this > thread is that the results in this nascent field are far more broad than > are captured or described by the phrase "zero delay filter". wrong term :-p -- 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] Implicit integration is an important term, ZDF is not
To some extent, yes. While the terminology was coined earlier, two years ago we released a software that uses the very same filter algorithm in both ways: The feedback loop of the analogue counterpart was either realised with a unit delay or it was made instantaneous aka zero-delay-feedback with an iterative solver. We then used the term zero delay feedback filters in our marketing to point out the difference between those two methods. Because really, that was the only difference in the actual code. Yet, the sound of the filters rendered with zero delay feedback is remarkably better - if one knows what to listen for. We can thus claim, and still do, that with same placement of non-linearities, literally same code, zero delay feedback filters have advantages over those using a unit delay. It's quite simple, really, and meant quite literally so. It has nothing to do with the way any analogue filter was analysed and recreated in code. The product in question has been received very well in the music community. This led to an inflationary use of the word zero delay feedback filters in marketing, up to the point where (desperate?) people who had no idea what it meant used the word in a confusing fashion: Suddenly some manufacturers of competing products would cough up the term "zero delay filter", which wasn't meant as a joke, but was just plain idiotism. It put the terminology itself into questionably territory. So what's happening here is, a term that - for us and maybe others too - is perfectly relevant and which builds an integral part of our generally modest marketing strategy, is being slammed in a most unfortunate way. That said, I have a good laugh at many puzzling marketing campaigns out there, but I wouldn't go and talk them down. It's just not good style. - Urs On 14.11.2013, at 12:31, Max Little wrote: > I've been following this somewhat heated discussion for a while! I've > not read the appropriate literature, but does this really just revolve > around whether someone uses implicit versus explicit finite difference > methods for nonlinear ODE models of analog circuits? > > Max > > > On 14 November 2013 11:26, Urs Heckmann wrote: >> My point is, >> >> It's not the fault of those who use the term in a correct way that some >> others have used it in a confusing way. >> >> That however doesn't justify a general - at times derogative - rant against >> using the term. I don't think it's very clever either. >> >> I'll leave it at that. >> >> - Urs >> >> On 14.11.2013, at 12:06, Dave Gamble wrote: >> >>> Hey Urs, >>> >>> Not quite sure if this was aimed at me or Andy, though it doesn't make a >>> ton of sense with either. >>> >>> Just in case it was aimed at me, I've never ever denied the utility of >>> Andy&Vadim's work; quite the opposite. >>> I'm not sure I've even ranted about the phrase. Just documented its history >>> and explained how it caused confusion. >>> >>> Dave. >>> >>> On Thursday, November 14, 2013, Urs Heckmann wrote: >>> Hehehe, Our methods of filter design, which are created merely from the viewpoint of algorithm design than from the perspective of "conformity with EE terms" is all about eliminating the unit delay - or using it as performance optimisation. I respect your viewpoint, but quite honestly, you're not doing anyone a favour if you deny the usefulness of "eliminating the unit delay in typical dsp implementations of analogue filter topologies". You use DF filters to base your rant about the terminology, when quite clearly the filters that people refer to as having a unit delay in the feedback path are different ones, such as Stilson/Smith's proposed Moog ladder implementation or Chamberlin's SVF. As much irony as there may be in the fact that DF filters are *transformed implementations* of zero delay feedback free filter models (!), their implementation necessarily requires an algorithmic structure that draws all of its disadvantages from its dependency on unit delays. It's doubleplus ironic because those abstract filters aren't even usable to recreate models that are not LTI. Poles and Zeros are great for a very limited aspect of filter design, but there's no representation of nonlinear elements in them. They're half the truth, as much as using the, for your rant is half the truth. Anyhow. Algorithms. We however don't give a shit at how we arrive at the algorithm we're using. There's not a single ultimate way to go about. Starting with a nodal analysis of a circuit is one way, and it's sometimes the harder one. Because research was already done (Stilson/Smith and Chamberlin for starters) and implementations already exist that are based on Euler. In those cases it's the more obvious way to eliminate the unit delay. And then there's one thing that ultimately
Re: [music-dsp] Implicit integration is an important term, ZDF is not
Thanks Dave. If that's really the case, then the phrase 'zero delay filter' is very misleading, because it seems to imply that there is no relationship between samples in time which clearly cannot be the case (otherwise, e.g. oscillation would be impossible for the continuous-state dynamical systems we are dealing with here - it is a simple argument to show that you need a state-space of at least two dimensions to allow oscillation). Just because one cannot rearrange the finite difference system to isolate the next time sample to be computed on the left hand side of an equation, doesn't mean that the time samples are not functionally related. I may have misread, but the discussion seems to suggest that this discipline is just discovering implicit finite differencing! Is that really the case? If so, that would be odd, because implicit methods have been around for a very long time in numerical analysis. Max On 14 November 2013 12:20, Dave Gamble wrote: > Hi, > > On Thursday, November 14, 2013, Max Little wrote: > >> I've been following this somewhat heated discussion for a while! I've >> not read the appropriate literature, but does this really just revolve >> around whether someone uses implicit versus explicit finite difference >> methods for nonlinear ODE models of analog circuits. > > Basically, yes. > I have a strong suspicion that these techniques will be making their way > into much more common usage in audio (I think it's fair to claim that > they're currently only in use at the cutting edge), and into courses etc, > so I think it's reasonable that there's some to-ing and fro-ing about > terminology, especially since this stuff does come with a really > significant set of results (filter topologies etc). > The thing is, the appropriate literature is something of a gold mine, and > so this is something akin to a discussion of what should be written on the > placard above the entrance. > > The "zero delay filters" name is meaningful to those already expert in the > field, but less so for newcomers who won't be aware of exactly which delay > it is that's been obviated. And the point Andy makes when starting this > thread is that the results in this nascent field are far more broad than > are captured or described by the phrase "zero delay filter". > > This is the language thread that exists in parallel to the technical > implicit/explicit methods threads. > > Dave. > > > >> > > >> > Max >> >> >> On 14 November 2013 11:26, Urs Heckmann wrote: >> > My point is, >> > >> > It's not the fault of those who use the term in a correct way that some >> others have used it in a confusing way. >> > >> > That however doesn't justify a general - at times derogative - rant >> against using the term. I don't think it's very clever either. >> > >> > I'll leave it at that. >> > >> > - Urs >> > >> > On 14.11.2013, at 12:06, Dave Gamble wrote: >> > >> >> Hey Urs, >> >> >> >> Not quite sure if this was aimed at me or Andy, though it doesn't make a >> >> ton of sense with either. >> >> >> >> Just in case it was aimed at me, I've never ever denied the utility of >> >> Andy&Vadim's work; quite the opposite. >> >> I'm not sure I've even ranted about the phrase. Just documented its >> history >> >> and explained how it caused confusion. >> >> >> >> Dave. >> >> >> >> On Thursday, November 14, 2013, Urs Heckmann wrote: >> >> >> >>> Hehehe, >> >>> >> >>> Our methods of filter design, which are created merely from the >> viewpoint >> >>> of algorithm design than from the perspective of "conformity with EE >> terms" >> >>> is all about eliminating the unit delay - or using it as performance >> >>> optimisation. >> >>> >> >>> I respect your viewpoint, but quite honestly, you're not doing anyone a >> >>> favour if you deny the usefulness of "eliminating the unit delay in >> typical >> >>> dsp implementations of analogue filter topologies". >> >>> >> >>> You use DF filters to base your rant about the terminology, when quite >> >>> clearly the filters that people refer to as having a unit delay in the >> >>> feedback path are different ones, such as Stilson/Smith's proposed Moog >> >>> ladder implementation or Chamberlin's SVF. >> >>> >> >>> As much irony as there may be in the fact that DF filters are >> *transformed >> >>> implementations* of zero delay feedback free filter models (!), their >> >>> implementation necessarily requires an algorithmic structure that >> draws all >> >>> of its disadvantages from its dependency on unit delays. It's >> doubleplus >> >>> ironic because those abstract filters aren't even usable to recreate >> models >> >>> that are not LTI. Poles and Zeros are great for a very limited aspect >> of >> >>> filter design, but there's no representation of nonlinear elements in >> them. >> >>> They're half the truth, as much as using the, for your rant is half the >> >>> truth. >> >>> >> >>> Anyhow. Algorithms. We however don't give a shit at how we arrive at >> the >> >>> algorithm we're using. There's n
Re: [music-dsp] Implicit integration is an important term, ZDF is not
Hi, On Thursday, November 14, 2013, Max Little wrote: > I've been following this somewhat heated discussion for a while! I've > not read the appropriate literature, but does this really just revolve > around whether someone uses implicit versus explicit finite difference > methods for nonlinear ODE models of analog circuits. Basically, yes. I have a strong suspicion that these techniques will be making their way into much more common usage in audio (I think it's fair to claim that they're currently only in use at the cutting edge), and into courses etc, so I think it's reasonable that there's some to-ing and fro-ing about terminology, especially since this stuff does come with a really significant set of results (filter topologies etc). The thing is, the appropriate literature is something of a gold mine, and so this is something akin to a discussion of what should be written on the placard above the entrance. The "zero delay filters" name is meaningful to those already expert in the field, but less so for newcomers who won't be aware of exactly which delay it is that's been obviated. And the point Andy makes when starting this thread is that the results in this nascent field are far more broad than are captured or described by the phrase "zero delay filter". This is the language thread that exists in parallel to the technical implicit/explicit methods threads. Dave. > > Max > > > On 14 November 2013 11:26, Urs Heckmann wrote: > > My point is, > > > > It's not the fault of those who use the term in a correct way that some > others have used it in a confusing way. > > > > That however doesn't justify a general - at times derogative - rant > against using the term. I don't think it's very clever either. > > > > I'll leave it at that. > > > > - Urs > > > > On 14.11.2013, at 12:06, Dave Gamble wrote: > > > >> Hey Urs, > >> > >> Not quite sure if this was aimed at me or Andy, though it doesn't make a > >> ton of sense with either. > >> > >> Just in case it was aimed at me, I've never ever denied the utility of > >> Andy&Vadim's work; quite the opposite. > >> I'm not sure I've even ranted about the phrase. Just documented its > history > >> and explained how it caused confusion. > >> > >> Dave. > >> > >> On Thursday, November 14, 2013, Urs Heckmann wrote: > >> > >>> Hehehe, > >>> > >>> Our methods of filter design, which are created merely from the > viewpoint > >>> of algorithm design than from the perspective of "conformity with EE > terms" > >>> is all about eliminating the unit delay - or using it as performance > >>> optimisation. > >>> > >>> I respect your viewpoint, but quite honestly, you're not doing anyone a > >>> favour if you deny the usefulness of "eliminating the unit delay in > typical > >>> dsp implementations of analogue filter topologies". > >>> > >>> You use DF filters to base your rant about the terminology, when quite > >>> clearly the filters that people refer to as having a unit delay in the > >>> feedback path are different ones, such as Stilson/Smith's proposed Moog > >>> ladder implementation or Chamberlin's SVF. > >>> > >>> As much irony as there may be in the fact that DF filters are > *transformed > >>> implementations* of zero delay feedback free filter models (!), their > >>> implementation necessarily requires an algorithmic structure that > draws all > >>> of its disadvantages from its dependency on unit delays. It's > doubleplus > >>> ironic because those abstract filters aren't even usable to recreate > models > >>> that are not LTI. Poles and Zeros are great for a very limited aspect > of > >>> filter design, but there's no representation of nonlinear elements in > them. > >>> They're half the truth, as much as using the, for your rant is half the > >>> truth. > >>> > >>> Anyhow. Algorithms. We however don't give a shit at how we arrive at > the > >>> algorithm we're using. There's not a single ultimate way to go about. > >>> Starting with a nodal analysis of a circuit is one way, and it's > sometimes > >>> the harder one. Because research was already done (Stilson/Smith and > >>> Chamberlin for starters) and implementations already exist that are > based > >>> on Euler. In those cases it's the more obvious way to eliminate the > unit > >>> delay. > >>> > >>> And then there's one thing that ultimately makes things worse from the > >>> viewpoint of "theorists": Any such implementation needs to be fine > tuned by > >>> ear. No analogue circuit reveals all of its character by the > description of > >>> the parts. Heck, if it was designed with the s-plane model in mind, it > was > >>> designed with a model that approximates reality in a very unmusical > way. I > >>> betcha the guys at Moog labs have fine tuned their first designs by > ear as > >>> well, until the got the right make of transistors and capacitors and > until > >>> it sounded good. Hence necessarily we have to do so too - the > schematics > >>> don't say it all. Even if there was a realtime Spice simulat
Re: [music-dsp] Implicit integration is an important term, ZDF is not
Heya, I've re-read my posts, and I found one that I can see could cause a little offence. That wasn't my intention, and wasn't how I meant it to come across. I intended the phrase "bullsh*t" to be read in the most general sense of marketing using buzzwords, not anything specific to this thread. I'm not saying I felt patronised (by my failing to read the sarcasm in Andy's post), but I do feel like he should be teaching me how to fish, or play baseball or something! :) Dave. On Thursday, November 14, 2013, Urs Heckmann wrote: > My point is, > > It's not the fault of those who use the term in a correct way that some > others have used it in a confusing way. > > That however doesn't justify a general - at times derogative - rant > against using the term. I don't think it's very clever either. > > I'll leave it at that. > > - Urs > > On 14.11.2013, at 12:06, Dave Gamble > > wrote: > > > Hey Urs, > > > > Not quite sure if this was aimed at me or Andy, though it doesn't make a > > ton of sense with either. > > > > Just in case it was aimed at me, I've never ever denied the utility of > > Andy&Vadim's work; quite the opposite. > > I'm not sure I've even ranted about the phrase. Just documented its > history > > and explained how it caused confusion. > > > > Dave. > > > > On Thursday, November 14, 2013, Urs Heckmann wrote: > > > >> Hehehe, > >> > >> Our methods of filter design, which are created merely from the > viewpoint > >> of algorithm design than from the perspective of "conformity with EE > terms" > >> is all about eliminating the unit delay - or using it as performance > >> optimisation. > >> > >> I respect your viewpoint, but quite honestly, you're not doing anyone a > >> favour if you deny the usefulness of "eliminating the unit delay in > typical > >> dsp implementations of analogue filter topologies". > >> > >> You use DF filters to base your rant about the terminology, when quite > >> clearly the filters that people refer to as having a unit delay in the > >> feedback path are different ones, such as Stilson/Smith's proposed Moog > >> ladder implementation or Chamberlin's SVF. > >> > >> As much irony as there may be in the fact that DF filters are > *transformed > >> implementations* of zero delay feedback free filter models (!), their > >> implementation necessarily requires an algorithmic structure that draws > all > >> of its disadvantages from its dependency on unit delays. It's doubleplus > >> ironic because those abstract filters aren't even usable to recreate > models > >> that are not LTI. Poles and Zeros are great for a very limited aspect of > >> filter design, but there's no representation of nonlinear elements in > them. > >> They're half the truth, as much as using the, for your rant is half the > >> truth. > >> > >> Anyhow. Algorithms. We however don't give a shit at how we arrive at the > >> algorithm we're using. There's not a single ultimate way to go about. > >> Starting with a nodal analysis of a circuit is one way, and it's > sometimes > >> the harder one. Because research was already done (Stilson/Smith and > >> Chamberlin for starters) and implementations already exist that are > based > >> on Euler. In those cases it's the more obvious way to eliminate the unit > >> delay. > >> > >> And then there's one thing that ultimately makes things worse from the > >> viewpoint of "theorists": Any such implementation needs to be fine > tuned by > >> ear. No analogue circuit reveals all of its character by the > description of > >> the parts. Heck, if it was designed with the s-plane model in mind, it > was > >> designed with a model that approximates reality in a very unmusical > way. I > >> betcha the guys at Moog labs have fine tuned their first designs by ear > as > >> well, until the got the right make of transistors and capacitors and > until > >> it sounded good. Hence necessarily we have to do so too - the schematics > >> don't say it all. Even if there was a realtime Spice simulator, the > outcome > >> wouldn't necessarily sound great. Maybe that's also why some don't think > >> that much in EE terms and more in terms of algorithms that lend > themselves > >> towards tweakability. > >> > >> There you go. It's sad that some blurtards have caused confusion with > >> stupid terminology - I'm talking about the zero delay filter misnomer. > That > >> however doesn't make it seem less arrogant to make fun of people who > >> practice "eliminating the unit delay" as their method. Because for those > >> and their point of view, zero delay feedback is relevant. > >> > >> - Urs > >> > >> right from my iPad > >> > >> Am 13.11.2013 um 23:42 schrieb Andrew Simper > >> > > >>> : > >> > >>> On 14 November 2013 01:28, Dave Gamble > > > >> wrote: > >>> > On Wed, Nov 13, 2013 at 2:29 PM, Andrew Simper > > > > >> wrote: > > > On 13 November 2013 20:00, Urs Heckmann > > > >> wrote: > > > >> On 13.11.2013, at 07:50, Andrew Simper > > > >> wrote: > >> >
Re: [music-dsp] Implicit integration is an important term, ZDF is not
I've been following this somewhat heated discussion for a while! I've not read the appropriate literature, but does this really just revolve around whether someone uses implicit versus explicit finite difference methods for nonlinear ODE models of analog circuits? Max On 14 November 2013 11:26, Urs Heckmann wrote: > My point is, > > It's not the fault of those who use the term in a correct way that some > others have used it in a confusing way. > > That however doesn't justify a general - at times derogative - rant against > using the term. I don't think it's very clever either. > > I'll leave it at that. > > - Urs > > On 14.11.2013, at 12:06, Dave Gamble wrote: > >> Hey Urs, >> >> Not quite sure if this was aimed at me or Andy, though it doesn't make a >> ton of sense with either. >> >> Just in case it was aimed at me, I've never ever denied the utility of >> Andy&Vadim's work; quite the opposite. >> I'm not sure I've even ranted about the phrase. Just documented its history >> and explained how it caused confusion. >> >> Dave. >> >> On Thursday, November 14, 2013, Urs Heckmann wrote: >> >>> Hehehe, >>> >>> Our methods of filter design, which are created merely from the viewpoint >>> of algorithm design than from the perspective of "conformity with EE terms" >>> is all about eliminating the unit delay - or using it as performance >>> optimisation. >>> >>> I respect your viewpoint, but quite honestly, you're not doing anyone a >>> favour if you deny the usefulness of "eliminating the unit delay in typical >>> dsp implementations of analogue filter topologies". >>> >>> You use DF filters to base your rant about the terminology, when quite >>> clearly the filters that people refer to as having a unit delay in the >>> feedback path are different ones, such as Stilson/Smith's proposed Moog >>> ladder implementation or Chamberlin's SVF. >>> >>> As much irony as there may be in the fact that DF filters are *transformed >>> implementations* of zero delay feedback free filter models (!), their >>> implementation necessarily requires an algorithmic structure that draws all >>> of its disadvantages from its dependency on unit delays. It's doubleplus >>> ironic because those abstract filters aren't even usable to recreate models >>> that are not LTI. Poles and Zeros are great for a very limited aspect of >>> filter design, but there's no representation of nonlinear elements in them. >>> They're half the truth, as much as using the, for your rant is half the >>> truth. >>> >>> Anyhow. Algorithms. We however don't give a shit at how we arrive at the >>> algorithm we're using. There's not a single ultimate way to go about. >>> Starting with a nodal analysis of a circuit is one way, and it's sometimes >>> the harder one. Because research was already done (Stilson/Smith and >>> Chamberlin for starters) and implementations already exist that are based >>> on Euler. In those cases it's the more obvious way to eliminate the unit >>> delay. >>> >>> And then there's one thing that ultimately makes things worse from the >>> viewpoint of "theorists": Any such implementation needs to be fine tuned by >>> ear. No analogue circuit reveals all of its character by the description of >>> the parts. Heck, if it was designed with the s-plane model in mind, it was >>> designed with a model that approximates reality in a very unmusical way. I >>> betcha the guys at Moog labs have fine tuned their first designs by ear as >>> well, until the got the right make of transistors and capacitors and until >>> it sounded good. Hence necessarily we have to do so too - the schematics >>> don't say it all. Even if there was a realtime Spice simulator, the outcome >>> wouldn't necessarily sound great. Maybe that's also why some don't think >>> that much in EE terms and more in terms of algorithms that lend themselves >>> towards tweakability. >>> >>> There you go. It's sad that some blurtards have caused confusion with >>> stupid terminology - I'm talking about the zero delay filter misnomer. That >>> however doesn't make it seem less arrogant to make fun of people who >>> practice "eliminating the unit delay" as their method. Because for those >>> and their point of view, zero delay feedback is relevant. >>> >>> - Urs >>> >>> right from my iPad >>> >>> Am 13.11.2013 um 23:42 schrieb Andrew Simper : >>> On 14 November 2013 01:28, Dave Gamble > >>> wrote: > On Wed, Nov 13, 2013 at 2:29 PM, Andrew Simper > > >>> wrote: > >> On 13 November 2013 20:00, Urs Heckmann > >>> wrote: >> >>> On 13.11.2013, at 07:50, Andrew Simper > >>> wrote: >>> I hope this clears things up and exposes ZDF as a confusing and >> pointless marketing catch phrase. >>> >>> It's not pointless for marketing in the sense that instantaneous > feedback >>> is much easier to explain than implicit integration. Users usually > don't >>> have profound knowledge of maths, whereas a delayless fee
Re: [music-dsp] Implicit integration is an important term, ZDF is not
My point is, It's not the fault of those who use the term in a correct way that some others have used it in a confusing way. That however doesn't justify a general - at times derogative - rant against using the term. I don't think it's very clever either. I'll leave it at that. - Urs On 14.11.2013, at 12:06, Dave Gamble wrote: > Hey Urs, > > Not quite sure if this was aimed at me or Andy, though it doesn't make a > ton of sense with either. > > Just in case it was aimed at me, I've never ever denied the utility of > Andy&Vadim's work; quite the opposite. > I'm not sure I've even ranted about the phrase. Just documented its history > and explained how it caused confusion. > > Dave. > > On Thursday, November 14, 2013, Urs Heckmann wrote: > >> Hehehe, >> >> Our methods of filter design, which are created merely from the viewpoint >> of algorithm design than from the perspective of "conformity with EE terms" >> is all about eliminating the unit delay - or using it as performance >> optimisation. >> >> I respect your viewpoint, but quite honestly, you're not doing anyone a >> favour if you deny the usefulness of "eliminating the unit delay in typical >> dsp implementations of analogue filter topologies". >> >> You use DF filters to base your rant about the terminology, when quite >> clearly the filters that people refer to as having a unit delay in the >> feedback path are different ones, such as Stilson/Smith's proposed Moog >> ladder implementation or Chamberlin's SVF. >> >> As much irony as there may be in the fact that DF filters are *transformed >> implementations* of zero delay feedback free filter models (!), their >> implementation necessarily requires an algorithmic structure that draws all >> of its disadvantages from its dependency on unit delays. It's doubleplus >> ironic because those abstract filters aren't even usable to recreate models >> that are not LTI. Poles and Zeros are great for a very limited aspect of >> filter design, but there's no representation of nonlinear elements in them. >> They're half the truth, as much as using the, for your rant is half the >> truth. >> >> Anyhow. Algorithms. We however don't give a shit at how we arrive at the >> algorithm we're using. There's not a single ultimate way to go about. >> Starting with a nodal analysis of a circuit is one way, and it's sometimes >> the harder one. Because research was already done (Stilson/Smith and >> Chamberlin for starters) and implementations already exist that are based >> on Euler. In those cases it's the more obvious way to eliminate the unit >> delay. >> >> And then there's one thing that ultimately makes things worse from the >> viewpoint of "theorists": Any such implementation needs to be fine tuned by >> ear. No analogue circuit reveals all of its character by the description of >> the parts. Heck, if it was designed with the s-plane model in mind, it was >> designed with a model that approximates reality in a very unmusical way. I >> betcha the guys at Moog labs have fine tuned their first designs by ear as >> well, until the got the right make of transistors and capacitors and until >> it sounded good. Hence necessarily we have to do so too - the schematics >> don't say it all. Even if there was a realtime Spice simulator, the outcome >> wouldn't necessarily sound great. Maybe that's also why some don't think >> that much in EE terms and more in terms of algorithms that lend themselves >> towards tweakability. >> >> There you go. It's sad that some blurtards have caused confusion with >> stupid terminology - I'm talking about the zero delay filter misnomer. That >> however doesn't make it seem less arrogant to make fun of people who >> practice "eliminating the unit delay" as their method. Because for those >> and their point of view, zero delay feedback is relevant. >> >> - Urs >> >> right from my iPad >> >> Am 13.11.2013 um 23:42 schrieb Andrew Simper >>> : >> >>> On 14 November 2013 01:28, Dave Gamble > >> wrote: >>> On Wed, Nov 13, 2013 at 2:29 PM, Andrew Simper > >> wrote: > On 13 November 2013 20:00, Urs Heckmann > >> wrote: > >> On 13.11.2013, at 07:50, Andrew Simper > >> wrote: >> >>> I hope this clears things up and exposes ZDF as a confusing and > pointless >>> marketing catch phrase. >> >> It's not pointless for marketing in the sense that instantaneous feedback >> is much easier to explain than implicit integration. Users usually don't >> have profound knowledge of maths, whereas a delayless feedback loop is >> easily illustrated. In other words, we would lose customers if we >> advertised "uses implicit integration, yay" ;-) > > Well it is time for all people using DF1 to ratchet up their marketing and > start touting "[*] featuring Zero Delay Feedback technology!!" (go on Dave > Gamble I know you are just itching to do this ;) > > In opposites world, sure. Yo
Re: [music-dsp] Implicit integration is an important term, ZDF is not
Hey Urs, Not quite sure if this was aimed at me or Andy, though it doesn't make a ton of sense with either. Just in case it was aimed at me, I've never ever denied the utility of Andy&Vadim's work; quite the opposite. I'm not sure I've even ranted about the phrase. Just documented its history and explained how it caused confusion. Dave. On Thursday, November 14, 2013, Urs Heckmann wrote: > Hehehe, > > Our methods of filter design, which are created merely from the viewpoint > of algorithm design than from the perspective of "conformity with EE terms" > is all about eliminating the unit delay - or using it as performance > optimisation. > > I respect your viewpoint, but quite honestly, you're not doing anyone a > favour if you deny the usefulness of "eliminating the unit delay in typical > dsp implementations of analogue filter topologies". > > You use DF filters to base your rant about the terminology, when quite > clearly the filters that people refer to as having a unit delay in the > feedback path are different ones, such as Stilson/Smith's proposed Moog > ladder implementation or Chamberlin's SVF. > > As much irony as there may be in the fact that DF filters are *transformed > implementations* of zero delay feedback free filter models (!), their > implementation necessarily requires an algorithmic structure that draws all > of its disadvantages from its dependency on unit delays. It's doubleplus > ironic because those abstract filters aren't even usable to recreate models > that are not LTI. Poles and Zeros are great for a very limited aspect of > filter design, but there's no representation of nonlinear elements in them. > They're half the truth, as much as using the, for your rant is half the > truth. > > Anyhow. Algorithms. We however don't give a shit at how we arrive at the > algorithm we're using. There's not a single ultimate way to go about. > Starting with a nodal analysis of a circuit is one way, and it's sometimes > the harder one. Because research was already done (Stilson/Smith and > Chamberlin for starters) and implementations already exist that are based > on Euler. In those cases it's the more obvious way to eliminate the unit > delay. > > And then there's one thing that ultimately makes things worse from the > viewpoint of "theorists": Any such implementation needs to be fine tuned by > ear. No analogue circuit reveals all of its character by the description of > the parts. Heck, if it was designed with the s-plane model in mind, it was > designed with a model that approximates reality in a very unmusical way. I > betcha the guys at Moog labs have fine tuned their first designs by ear as > well, until the got the right make of transistors and capacitors and until > it sounded good. Hence necessarily we have to do so too - the schematics > don't say it all. Even if there was a realtime Spice simulator, the outcome > wouldn't necessarily sound great. Maybe that's also why some don't think > that much in EE terms and more in terms of algorithms that lend themselves > towards tweakability. > > There you go. It's sad that some blurtards have caused confusion with > stupid terminology - I'm talking about the zero delay filter misnomer. That > however doesn't make it seem less arrogant to make fun of people who > practice "eliminating the unit delay" as their method. Because for those > and their point of view, zero delay feedback is relevant. > > - Urs > > right from my iPad > > Am 13.11.2013 um 23:42 schrieb Andrew Simper > >: > > > On 14 November 2013 01:28, Dave Gamble > > wrote: > > > >> On Wed, Nov 13, 2013 at 2:29 PM, Andrew Simper > >> > > wrote: > >> > >>> On 13 November 2013 20:00, Urs Heckmann > > wrote: > >>> > On 13.11.2013, at 07:50, Andrew Simper > > wrote: > > > I hope this clears things up and exposes ZDF as a confusing and > >>> pointless > > marketing catch phrase. > > It's not pointless for marketing in the sense that instantaneous > >> feedback > is much easier to explain than implicit integration. Users usually > >> don't > have profound knowledge of maths, whereas a delayless feedback loop is > easily illustrated. In other words, we would lose customers if we > advertised "uses implicit integration, yay" ;-) > >>> > >>> Well it is time for all people using DF1 to ratchet up their marketing > >> and > >>> start touting "[*] featuring Zero Delay Feedback technology!!" (go on > >> Dave > >>> Gamble I know you are just itching to do this ;) > >>> > >>> In opposites world, sure. You may have me backwards. > >> > >> Despite my fairly inane sense of humour, I do strive (not always > >> successfully, of course) to avoid any kind of sensationalism that the > >> customer can see. > >> > >> I'm strongly anti-bullshit, because I'm just not very good at it. > >> > >> Dave. > > You have expressed quite clearly your distaste for this particular > > terminology, I'm just having fun :) > > -- > > dupswapdrop -- the music-dsp mailing
Re: [music-dsp] Implicit integration is an important term, ZDF is not
Hehehe, Our methods of filter design, which are created merely from the viewpoint of algorithm design than from the perspective of "conformity with EE terms" is all about eliminating the unit delay - or using it as performance optimisation. I respect your viewpoint, but quite honestly, you're not doing anyone a favour if you deny the usefulness of "eliminating the unit delay in typical dsp implementations of analogue filter topologies". You use DF filters to base your rant about the terminology, when quite clearly the filters that people refer to as having a unit delay in the feedback path are different ones, such as Stilson/Smith's proposed Moog ladder implementation or Chamberlin's SVF. As much irony as there may be in the fact that DF filters are *transformed implementations* of zero delay feedback free filter models (!), their implementation necessarily requires an algorithmic structure that draws all of its disadvantages from its dependency on unit delays. It's doubleplus ironic because those abstract filters aren't even usable to recreate models that are not LTI. Poles and Zeros are great for a very limited aspect of filter design, but there's no representation of nonlinear elements in them. They're half the truth, as much as using the, for your rant is half the truth. Anyhow. Algorithms. We however don't give a shit at how we arrive at the algorithm we're using. There's not a single ultimate way to go about. Starting with a nodal analysis of a circuit is one way, and it's sometimes the harder one. Because research was already done (Stilson/Smith and Chamberlin for starters) and implementations already exist that are based on Euler. In those cases it's the more obvious way to eliminate the unit delay. And then there's one thing that ultimately makes things worse from the viewpoint of "theorists": Any such implementation needs to be fine tuned by ear. No analogue circuit reveals all of its character by the description of the parts. Heck, if it was designed with the s-plane model in mind, it was designed with a model that approximates reality in a very unmusical way. I betcha the guys at Moog labs have fine tuned their first designs by ear as well, until the got the right make of transistors and capacitors and until it sounded good. Hence necessarily we have to do so too - the schematics don't say it all. Even if there was a realtime Spice simulator, the outcome wouldn't necessarily sound great. Maybe that's also why some don't think that much in EE terms and more in terms of algorithms that lend themselves towards tweakability. There you go. It's sad that some blurtards have caused confusion with stupid terminology - I'm talking about the zero delay filter misnomer. That however doesn't make it seem less arrogant to make fun of people who practice "eliminating the unit delay" as their method. Because for those and their point of view, zero delay feedback is relevant. - Urs right from my iPad Am 13.11.2013 um 23:42 schrieb Andrew Simper : > On 14 November 2013 01:28, Dave Gamble wrote: > >> On Wed, Nov 13, 2013 at 2:29 PM, Andrew Simper wrote: >> >>> On 13 November 2013 20:00, Urs Heckmann wrote: >>> On 13.11.2013, at 07:50, Andrew Simper wrote: > I hope this clears things up and exposes ZDF as a confusing and >>> pointless > marketing catch phrase. It's not pointless for marketing in the sense that instantaneous >> feedback is much easier to explain than implicit integration. Users usually >> don't have profound knowledge of maths, whereas a delayless feedback loop is easily illustrated. In other words, we would lose customers if we advertised "uses implicit integration, yay" ;-) >>> >>> Well it is time for all people using DF1 to ratchet up their marketing >> and >>> start touting "[*] featuring Zero Delay Feedback technology!!" (go on >> Dave >>> Gamble I know you are just itching to do this ;) >>> >>> In opposites world, sure. You may have me backwards. >> >> Despite my fairly inane sense of humour, I do strive (not always >> successfully, of course) to avoid any kind of sensationalism that the >> customer can see. >> >> I'm strongly anti-bullshit, because I'm just not very good at it. >> >> Dave. > You have expressed quite clearly your distaste for this particular > terminology, I'm just having fun :) > -- > 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] Implicit integration is an important term, ZDF is not
> > Every time I see a valve circuit with R|C to ground off the cathode, that's universally agreed to be feedback... But implicit, not explicit. > > I'm open to changing my definition of feedback, but I can't go with one > that requires me to assign the "direction" of a wire, cause that's not how > I imagine things. Why not go with feedback in both cases? > > As Wittgenstein said: "We are engaged in a struggle with language". > Although, for fairness, he did also say: "When we can't think for > ourselves, we can always quote". > > Dave. > > Implicit is I think a more useful term all up. But note that you also get an implicit equation from a basic diode clipper circuit with just one diode in serial with a resistor to ground without a capacitor anywhere or feedback. This is because the voltage appears as a linear term (the resistor) and an exponential term (for the diode), this is an implicit equation, but you also have implicit numerical integration, so really those are the terms that I think have meaning. To be more descriptive on top you can also add linear or nonlinear as well. But I still don't think the word implicit is useful for marketing, although I use it to describe things I understand my customers may not. 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
