Scroll down for new and improved or click https://forum.pdpatchrepo.info/topic/13621/20-mode-pole-mixing-and-morphing-filter-updated/10

Quick experiment that @jameslo got me thinking about, turned out well. You get 20 modes and you can morph between them. Probably has room for improvement, I do not do much audio work in pd. Enjoy.
polemix.zip

Scrap that- I forgot to fix the averageing filter in polemix2 - oversampling of 2 is fine: polefix2.zip

@bocanegra Turns out the difference in sound between the two was that 10 sample delay, no idea where it came from but it seems it snuck in early. Got a decent amount of rework to do. Working on a revision that is a mix of your filter and @tungee clipper, but need to rework the resonance morph, you can now hear the steps as each pole phase cancels and the resonance no longer gets aggressive enough to really highlight the morph, but I think I know how to do it. The same trick used in the filter morph should fix the stepping issue and a less soft clipper seems a good start, pretty decent with just [clip~] but not quite right.

As recent experiments have shown, you don't get correct frequency response with soft clipping anywhere in the circuit. For that you are better off using @solipp 's karlsen ladder: https://forum.pdpatchrepo.info/topic/13202/looking-for-help-for-optimisation-of-karlsen-24-db-ladder-filter/2 -- I tried inserting @tungee 's clipper in this one too and it screwed up the frequency response.

There are dozens of papers on digitizing the moog/4 pole ladder filter with endless suggestions on how to compensate for the non-linearities that arise when you go "discrete" with soft clip (tanh) emulations. You see, the resonance feedback has to be shifted 180 degrees and all the 1 sample delays screw that up even when oversampling and average filtering

Using cpole~ instead of rpole~ might be an option but i am not well versed in the complex plane...

The Karlsen-Ladder implementation is from Jaffasplaffa,, bocanegra.
https://forum.pdpatchrepo.info/topic/13202/looking-for-help-for-optimisation-of-karlsen-24-db-ladder-filter/35
Solipp's Ladder is in theory very nice also, but in practice without proper clipping it shoots some nasty peaks. if you use static frequencies, everythings sounds great but if you change the the frequency parameter in his ladder example file in his audiolab abstraction library, you will notice when you drag the slider into the low frenquency areas, dangerous peaks for your speaker.
https://forum.pdpatchrepo.info/topic/13202/looking-for-help-for-optimisation-of-karlsen-24-db-ladder-filter/35
In Jaffasplaffa's example, he managed somehow to use clipping without peak overshoots somehow.
In your example , we used the anaclip in the ladder bucket, what if we use anaclip only before the output?

@bocanegra Yeah, I have played with it some the other night, but I am not after a moog sound. I keep finding myself going back to [lop~], it seems to respond the most consistently, the discrete solutions all seem to have quirks especially in the resonance morph, some transitions result in no resonance as if it is out of phase and canceling. I am not sure if this is actually a thing, I half think my patch has one of those sorts of errors that can only be seen by sifting through it in a text editor, come weekend I plan on patching a handful of variations up from scratch and doing some sane comparisons, hopefully figure out why some resonance morphs result in phase cancellation despite their supposedly having proper phase. Also started to revisit and expand on that waveshaper in the Karlsen thread, reworking it to avoid the message rate stuff which was great for showing how it works but not so great for waveshaping, but does have some fun results.

@oid [lop~] is no less discrete than [rpole~]. All digital filters are discrete per definition. An ideal 1 pole lowpass shifts the phase at cutoff 45 degrees. In the digital realm we can only emulate filters employing delays, and those delays introduce phase distortion. (this is why we use oversampling and average filtering in the feedback loop)

The only thing I can come up with that would explain [lop~]'s stability is that cutoff is kept in the control message domain (?). Also, I think phase cancellations during polemixing/morphing is inevitable as some combos are allpasses/phasers...

@tungee

what if we use anaclip only before the output?

That would keep it from interfering with the filters frequency response, but you'd get stability issues with high feedback/resonance...
The best results I've had with anaclip/tanh stem from placing it in the feedback loop just before the resonance gain stage, i.e.:

But in the end you also have to ask yourself how important filter accuracy is in a musical context. When you fiddle with knobs on an analog synth's VCF you don't calculate exact frequencies...

"But in the end you also have to ask yourself how important filter accuracy is in a musical context. When you fiddle with knobs on an analog synth's VCF you don't calculate exact frequencies..."

This is exactly what i think also Bocanegra....
If i play with the Boca-ladder sliders within Automatonism, i trust my ears and there it sounds fantastic. Through the whole frequency spectrum (20hz- 11KHz) with all resonance values within the 0-20 range .
Thank you again

@bocanegra said:

[lop~] is no less discrete than [rpole~].

I am referring to it being made up from multiple objects instead of just one, analogy between transistors and integrated circuits.

Probably not control vs signal domain since they both have [mtof] on the cutoff so should be set to the exact same frequency. I am not talking about cancellation during the morph, as I said some transitions don't work, a resonance morph from 24db hp to 12db lp works but 24db hp to 18db lp results in the resonance results in the wrong phase after the morph, but a morph from 12db lp to 18db lp works just fine (don't recall if those actual transitions are the troublesome ones, just a random example). I suspect an error that can only be seen on the text level, order of operations (don't see anywhere this could be the issue) or an actual error which can not be seen in the patcher like the duplicate patch cable bug. I am fairly certain this just recently cropped up and the non-[lop~] filters did work but that might have just been an illusion caused by the mysterious 10 sample delay which had cropped up some how, I have no idea, hence starting over from scratch come weekend.

As an aside, know of any suitable externals which is essentially [lop~] with signal rate? I looked some but only found more complex filters, would be nice to have that CPU savings which [lop~] provides but keep signal rate inputs. Or is the CPU difference primarily the signal rate cutoff? Seems too great to be just that.

@oid said:

I am referring to it being made up from multiple objects instead of just one, analogy between transistors and integrated circuits.

Ok well, I was refering to the inherent phase shift that any digital filter has because of the discrete time and delay. No biggie.

Probably not control vs signal domain since they both have [mtof] on the cutoff so should be set to the exact same frequency. I am not talking about cancellation during the morph, as I said some transitions don't work, a resonance morph from 24db hp to 12db lp works but 24db hp to 18db lp results in the resonance results in the wrong phase after the morph, but a morph from 12db lp to 18db lp works just fine (don't recall if those actual transitions are the troublesome ones, just a random example). I suspect an error that can only be seen on the text level, order of operations (don't see anywhere this could be the issue) or an actual error which can not be seen in the patcher like the duplicate patch cable bug. I am fairly certain this just recently cropped up and the non-[lop~] filters did work but that might have just been an illusion caused by the mysterious 10 sample delay which had cropped up some how, I have no idea, hence starting over from scratch come weekend.

For resonance to work, there has to be a full 360 degree shift of the cut-off frequency while the other frequencies get cancelled/phased out. This works when you have 4 1 pole filters doing 45 degrees shift on the cutoff frequency each and then do negative (180 degree shift) feedback. But when you start mixing the different poles for the feedback you get all sorts of different phase distortions that wont create the magic self oscillation we love so much. Maybe try using the [filter-graph] abstractions from H10.measurement.pd to measure phase distortion on your resonance pole-mix and see what is going on.

As an aside, know of any suitable externals which is essentially [lop~] with signal rate? I looked some but only found more complex filters, would be nice to have that CPU savings which [lop~] provides but keep signal rate inputs. Or is the CPU difference primarily the signal rate cutoff? Seems too great to be just that.

I just ran a test on [rpole~] vs [lop~] (seppareately!)

Setting [rpole~] up like here, it works 'exactly* like [lop~]. They both spike at 30 CPU but stay at 20 most of the time. I think [rpole~] is as cheap as it gets with signal rate cut-off control. Of course, small differences add up when you have several instances.

@bocanegra Duh, that 10 sample delay strikes again. Think I might bring it back, perhaps that is how it ended up there and I just forgot about it? What are you using to measure CPU? with htop I get ~8% cpu use (6% being pd's DSP) for [lop~] and ~14% for [rpole~]. Is your computer that ancient or is the CPUs governor not kicking up to the next step with the low demands of your test patch? I tend to test audio stuff with the governor set on performance since most any practical audio patch will kick it up to the highest settings anyways, gives a more accurate result.

@oid said:

What are you using to measure CPU?

I am just counting on pd's native [cputime] object as you can see in the screenshot. I also have a widget in my task bar that graphs cpu cores and memory usage, but I only use that to tell me when it's time to close some fans in my browser and whatever programs I have left open. I just realized I can mouse hover the widget and get a reading

with htop I get ~8% cpu use (6% being pd's DSP) for [lop~] and ~14% for [rpole~].

That is when running the entire morphing filter, right?

Is your computer that ancient or is the CPUs governor not kicking up to the next step with the low demands of your test patch?

Nah. Bought it last christmas- 3.5gHz / 4 cores / 16gb ram. I just have a lot of stuff going on at the same time (gimp, geogebra, pd, multiple tabs in firefox, various documents.)

I tend to test audio stuff with the governor set on performance since most any practical audio patch will kick it up to the highest settings anyways, gives a more accurate result.

I rarely run into problems even with all my excess of open garbage haha. I did have pd freeze on me a couple of times yesterday while experimenting- but that was due to sheer recklessness

@bocanegra said:

That is when running the entire morphing filter, right?

Yes but I get similar results from just the objects themselves in practical use. Supposedly measuring cpu use with pd is very inaccurate, never tested it, just accepted what others said and have always went by htop.

@oid - right, let me try again, this time monitoring processes in my task manager to see how much pd uses exactly...

Running 10 instances of the rpole test pd-guiport spikes at 3% while pd gui-ctl stays at 3%
Running 10 instances of the lop test pd-guiport spikes at 2% while pd gui-ctl stays at 1%
So roughly twice the CPU usage for [rpole~]

This is a stress test with [block~ 1 1 2] though. I reckon that is harder on signal rate stuff than control messages.

that 10 sample delay strikes again. Think I might bring it back

Why though?

Because I like the sound better than cancellation and I do not care about it being a proper filter, end result is all that concerns me. Remember what you just said about accuracy?

@oid said:

Because I like the sound better than cancellation and I do not care about it being a proper filter, end result is all that concerns me. Remember what you just said about accuracy?

haha you are right

But then why not make it a [vd~] with optimized delay lengths for each topology and morphing?

Hmm wouldn't be far from this Oid to make a Oberheim 12db Filter?

https://www.kvraudio.com/forum/viewtopic.php?p=8194407

"I'm implementing a VA LadderFilter following Will Pirkle's synth book. A cascade of four VA one-pole filters is used to achieve the filter. However, there's a twist. From what is called Oberheim Variations, more filter responses (LP, BP, HP, each 2-pole or 4-pole) are achieved.

It is done by taking the outputs of each cascaded stage separately as well as the input and mixing them together following a set of coefficients A through E. So the equation goes like:

output = A * (input + feedback) + B * LPF1 + C * LPF2 + D * LPF3 + E * LPF4

I have the coefficients for the above mentioned filter types, but I recon there is more to be discovered.

The book references a research paper by Välimäki and Huovilainen, where these coefficients are taken from. However, the paper doesn't explain how the coefficients came to be.
A further reference points towards a service manual for the Oberheim Xpander. There's several relevant information on pages 26 and 27, but I don't see the connection between the provided information and the coefficients I already have.

So I was wondering if anybody could point me in the right direction, how to obtain the rest of the coefficients. I am particularly after the 3- and 1-pole versions, notch-filters and allpass-variants."

So the only missing piece in the puzzle are the A-E coeficients.

From the KVR Thread:
5.5 of VAFilterDesign (rev 2.1.2) contains an explanation of the principles.

https://archive.org/details/the-art-of-va-filter-design-rev.-2.1.2

Here is also a c++ example of an Oberheim Filter:
https://github.com/ddiakopoulos/MoogLadders/blob/master/src/OberheimVariationModel.h
My math is not so good to understand this

@tungee the whole pole mixing separate outputs from a ladder filter was first done by the Oberheim Xpander and is explained well here with all coefficients mapped out: https://electricdruid.net/multimode-filters-part-2-pole-mixing-filters/

It is exactly what @oid has been up to, but with a morph between mixes twist

You can do it with the filter I made using the coefficients explained in the link- or use the filter @solipp posted in the [bob~] thread

Also, The Art Of VA Filter Design is a very good read, but rather dense on the math side

Ah ok! This is great, im testing it now. Thanx OID and Bocanegra... Trying to implement it as a Automatonism Module now .

@tungee - Be mindful of the inversion pattern after the end of each filter stage. Oid and I put inverters after each. IIRC solipp put none, and thus stage 2 and 4 need inversion ( [*~ -1] ) before applying pole-mix coefficients.

And don't forget to share your filter when it's working (new thread maybe?)

@tungee If memory serves, Bernie Hutchins (originator of the filter) covers everything you need in his original article on the topic, http://electronotes.netfirms.com/EN85VCF.pdf.