Steiner Parker filter topology

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Scrap that. C1 and C3 are shortcut on one side. I guess that means one could simplify the circuit... :dog:

Post

Thanks a lot!
giq

Post

Guys

Code: Select all

        +     -
    +---(Vbias)---+
    |             |
    |             |
----+----->|------+------
               | 
               =
               |
               gnd

Input voltage is added to bias voltage so, frequency of the filter is modulated by exp(input*ratio) am I right? I assume this effect is minimal but its present.
giq

Post

itoa wrote:Guys

Code: Select all

        +     -
    +---(Vbias)---+
    |             |
    |             |
----+----->|------+------
               | 
               =
               |
               gnd

Input voltage is added to bias voltage so, frequency of the filter is modulated by exp(input*ratio) am I right? I assume this effect is minimal but its present.
Yes, that is correct. Furthermore the stages are not buffered. Which is why a more or less accurate model of a diode filter is a magnifold more difficult to achieve than a model of a transistor/OpAmp based filter.

Actually the formula for filter frequency modulation might be a bit more complex, such like exp( input + bias ) - exp ( bias ). But the term "filter frequency" doesn't really matter much once the circuit model is done based on Kirchhoff etc. Once you got the model you can map your "average filter frequency" to corresponding bias voltages.

Post

Ah so we shouldn't even try to model this with "naive nonlinearities" and call it Steiner Parker :]

Looking at your scheme, so when resonance is active C2 acts like a second LP in the loop.
giq

Post

(We've got papers on iterative solvers that are almost ready to go… just need some linguistic tweaks to make them sound right…)
Hello Urs ! I'm still very curious about that :D

Post

Ivan_C wrote:
(We've got papers on iterative solvers that are almost ready to go… just need some linguistic tweaks to make them sound right…)
Hello Urs ! I'm still very curious about that :D
There's a bit of movement... we found a very promising optimisation to iterative solvers. It currently beats whatever we used to do, but it also involves a lot more maths. There's also another twist to it that I do not yet fully understand. I'm still considering papers but I need the full picture.

Our next move is to conduct a large blind test to see how important this stuff is at all, i.e. whether or not people hear a significant difference in various levels of accuracy.

That said, I'm considering starting a blog about this stuff.

Post

btw. Urs

Isn't "cheap Mystran's" method + oversampling enough?
I found this very usable and got aliasing battle won by the way, even in stiff systems.

I don't hear any difference for high enough oversampling, except I can "push them stronger" in case of Mystran's method.
giq

Post

itoa wrote:btw. Urs

Isn't "cheap Mystran's" method + oversampling enough?
I found this very usable and got aliasing battle won by the way, even in stiff systems.

I don't hear any difference for high enough oversampling, except I can "push them stronger" in case of Mystran's method.
When I use an iterative method with an error margin that's much lower than the error in Mystran's method I can still hear a lot of noise. I presume the error in Mystran's method (or other methods that approximate tanh(x) by a*x + b) isn't as "random" as with iterative solvers, but it might have similar propagation over time.

Post

yep its all about performance/aliasing/quality balance.

Sometimes, where there is a single dominating nonlinearity, I solve this directly (it's usually doable using lambertW stuff) and then apply cheap method for the rest of them.
giq

Post

There's a bit of movement... we found a very promising optimisation to iterative solvers. It currently beats whatever we used to do, but it also involves a lot more maths. There's also another twist to it that I do not yet fully understand. I'm still considering papers but I need the full picture.

Our next move is to conduct a large blind test to see how important this stuff is at all, i.e. whether or not people hear a significant difference in various levels of accuracy.

That said, I'm considering starting a blog about this stuff.
Sounds really interesting ! Looking forward :D

Post

itoa wrote:yep its all about performance/aliasing/quality balance.

Sometimes, where there is a single dominating nonlinearity, I solve this directly (it's usually doable using lambertW stuff) and then apply cheap method for the rest of them.
lambertW sounds groovy, I haven't tried that yet.

We're currently optimizing multiple unknowns with Newton Raphson. This way we can parallelize several filter stages in SSE code even for monophonic filters. As this converges in 2-3 rounds for filters with buffers, it's pretty much almost as fast as any one step method with an added correction step, as long as a few tanhs() are involved, or anything with similarly nice derivatives.

Post

Hmm.. What with feedback and dependencies then? When you compute stages separately? Error gets propagated to following stages

As for LambertW.. This is the whole world of possibilities.
When you forget about tanh and replace it with nonlinearity that comes from y = y - sign(y)*exp(|y|*a)*b you have a nice bunch of sigmoids that often approximate things better than tanh. (e.g. for OTAs)

And... this is solvable :]
Last edited by itoa on Wed Jan 27, 2016 8:45 am, edited 1 time in total.
giq

Post

itoa wrote:Hmm.. What with feedback then? When you compute stages separately?
You estimate all output voltages, say y1Estimate... y4Estimate in a ladder filter. Then you optimise for zeros in the error function yn - ynEstimate. That way all feedbacks are included in the estimates.
As for LambertW.. This is the whole world of possibilities.
When you forget about tanh and replace it with nonlinearity that comes from y = y - sign(y)*exp(|y|*a)*b you have a nice bunch of sigmoids that often approximate things better than tanh.

And... this is solvable :]
Hah, I must check that out one day!

Post

Ivan_C wrote:
(We've got papers on iterative solvers that are almost ready to go… just need some linguistic tweaks to make them sound right…)
Hello Urs ! I'm still very curious about that :D
Same here :)

Post Reply

Return to “DSP and Plugin Development”