Cheap non-linear zero-delay filters

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Besides using stock LU, the other change I might do if I revised the original filter code would be to not solve for any of the outputs (except obviously the one we want, whether that's a single pole or some combination). There's no real need to do so. Just write the whole thing in terms of the state variables, observing that you can solve "half the backwards-step" from the new solution, instead of "half the forward-step" from the old one (so you get new states directly as the solutions of the unknowns). Not sure if it would make a difference here, but for a more complex circuits it can save some work.

Basically, when you forget about block diagrams and signal flow, and just treat it as "another pile of math" there's quite a few such trick you can do. :)

Post

mystran wrote:The serious part then is that the only way I personally can read a block-diagram is to convert it into equations (or something similar), and it usually takes several attempts before I'm confident that I actually got it right (which doesn't necessarily mean I actually got it right). I'd rather describe them as frightening rather than intuitive. But I also can't do geometry without converting it to algebra first, so maybe I'm just stupid. YMMV.
So, you'd say that understanding the ladder filter as a serial chain of 4 1-pole lowpasses with feedback is frightening? :shock:

Post

Z1202 wrote:
mystran wrote:The serious part then is that the only way I personally can read a block-diagram is to convert it into equations (or something similar), and it usually takes several attempts before I'm confident that I actually got it right (which doesn't necessarily mean I actually got it right). I'd rather describe them as frightening rather than intuitive. But I also can't do geometry without converting it to algebra first, so maybe I'm just stupid. YMMV.
So, you'd say that understanding the ladder filter as a serial chain of 4 1-pole lowpasses with feedback is frightening? :shock:
No. I'm saying that if you DRAW 4 boxes and an arrow around it, it's already a bit scary, and if you further expand the DRAWING to the level of individual delays (let alone non-linearities) the mental effort to comprehend it gets so high that I won't even try, if I have a choice.

Post

Agree with that actually, I also find equations more intuitive than block diagrams which I've always hated once hey have more than a few boxes.
I think we're in the minority though :)

Post

mystran wrote:
Z1202 wrote:
mystran wrote:The serious part then is that the only way I personally can read a block-diagram is to convert it into equations (or something similar), and it usually takes several attempts before I'm confident that I actually got it right (which doesn't necessarily mean I actually got it right). I'd rather describe them as frightening rather than intuitive. But I also can't do geometry without converting it to algebra first, so maybe I'm just stupid. YMMV.
So, you'd say that understanding the ladder filter as a serial chain of 4 1-pole lowpasses with feedback is frightening? :shock:
No. I'm saying that if you DRAW 4 boxes and an arrow around it, it's already a bit scary, and if you further expand the DRAWING to the level of individual delays (let alone non-linearities) the mental effort to comprehend it gets so high that I won't even try, if I have a choice.
Full expansion is rarely, if ever, necessary. One of the beauties of the block-diagram approach is that you typically restrict a diagram to a given level. E.g. you can have a diagram of a BLT integrator, a diagram of a 1-pole filter which is using the integrator and a diagram of the ladder filter using 4xLP1 (actually, the two latter diagrams are the same for both analog and digital cases). I'm not sure, how to have and/or control the same kind of structural thinking on the equation level.

Edit: furthermore, in the nonlinear Antti's model case, if you do a local 1-level expansion (consider two 1-poles in series) you can immediately notice that the two tanh-s are using the same input signal and thus can be collapsed into a single tanh. With a regular math notation with indexed states this seems to me less obvious.

Post

FastTriggerFish wrote:Agree with that actually, I also find equations more intuitive than block diagrams which I've always hated once hey have more than a few boxes.
I think we're in the minority though :)
See, I'm not the only one with that part of brain missing..

Post

mystran wrote: Anyway, should probably update the original algorithm for a more efficient reduction, in case someone still cares..
I would very much appreciate it :)

Post

I have to agree that those diagrams with the unit delays all over them are ultra confusing for me too. I always use and much prefer a straight out circuit diagram, this tells you all you need to know ie the names and positions of components and the number of nodes / voltages / currents to solve for and you can do the modelling using whichever numerical integration scheme you want, even different schemes for different components if you want. Drawing in all the unit delays to me seems like a complete waste of time and just adds clutter to an otherwise useful diagram.
The Glue, The Drop - www.cytomic.com

Post

andy_cytomic wrote:I have to agree that those diagrams with the unit delays all over them are ultra confusing for me too.
So are they to me. However, analog-domain block diagrams are a completely different story, those are much more intuitive. Once you implicitly understand a discrete-time integration scheme under an analog-domain integrator item, you don't need any specific discrete-time diagrams. So much for the unit delays ;)

Post

Z1202 wrote:
andy_cytomic wrote:I have to agree that those diagrams with the unit delays all over them are ultra confusing for me too.
So are they to me. However, analog-domain block diagrams are a completely different story, those are much more intuitive. Once you implicitly understand a discrete-time integration scheme under an analog-domain integrator item, you don't need any specific discrete-time diagrams. So much for the unit delays ;)
Well you're changing your tune here. I recall that you wrote an email to me after I published my modified SVF structure that "I prefer a graphical approach and will need to map your equations against what is graphically obtained from the integrator substitution technique.", which to me sounds like you like all the z^-1 terms in the diagram!
The Glue, The Drop - www.cytomic.com

Post

andy_cytomic wrote:
Z1202 wrote:
andy_cytomic wrote:I have to agree that those diagrams with the unit delays all over them are ultra confusing for me too.
So are they to me. However, analog-domain block diagrams are a completely different story, those are much more intuitive. Once you implicitly understand a discrete-time integration scheme under an analog-domain integrator item, you don't need any specific discrete-time diagrams. So much for the unit delays ;)
Well you're changing your tune here. I recall that you wrote an email to me after I published my modified SVF structure that "I prefer a graphical approach and will need to map your equations against what is graphically obtained from the integrator substitution technique.", which to me sounds like you like all the z^-1 terms in the diagram!
I don't think so. I do find the equations less intuitive than the corresponding diagrams in general. So, yes, I do prefer unit-delay diagrams to the difference equations, if that is the choice (talking our email exchange). However, normally I don't have to make that choice, as explained earlier. In the TPT method one almost exclusively works with analog-domain diagrams of various levels. At the lowest level, those contain integrators, not unit-delays.

Post

courses, or horses?
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

rola wrote:
mystran wrote: Anyway, should probably update the original algorithm for a more efficient reduction, in case someone still cares..
I would very much appreciate it :)
:tu:

Post

Ichad.c wrote:
rola wrote:
mystran wrote: Anyway, should probably update the original algorithm for a more efficient reduction, in case someone still cares..
I would very much appreciate it :)
:tu:
Ok, I'll try to make myself do it. It's not like the difference is going to be huge though (basically should save one division, but that's about it).

Post

mystran wrote:
Ichad.c wrote:
rola wrote:
mystran wrote: Anyway, should probably update the original algorithm for a more efficient reduction, in case someone still cares..
I would very much appreciate it :)
:tu:
Ok, I'll try to make myself do it. It's not like the difference is going to be huge though (basically should save one division, but that's about it).
It's not really that much about cycle-saving to me - it's about perspective. Finding/understanding different angles of thought might help somewhere along the line with something else.

That being said - I do appreciate your 'writing style' -> highly practical with relativly, easily digestible theory.

P.S. Thanks for that thread long ago about the pole-mixing of the x-pander - it works like a charm!

Andrew

Post Reply

Return to “DSP and Plugin Development”