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

@oid said:

http://electronotes.netfirms.com/EN85VCF.pdf.

Awesome find! BUT- the problem, as you have pointed out in this thread before, is that analog circuitry math does not translate well to digital, especially in the case of filters. https://archive.org/details/the-art-of-va-filter-design-rev.-2.1.2 was an eye-opener for me in terms of the limitations of our standard digital 1 pole algorithm.

The TPT filter suggested (which solipp employs in his ladder filter) solves a LOT of the problems we have been struggling with. However, there is no way to implement it cpu-cheap unless someone sits down and makes an external [tpt_lop~] object (with signal rate cutoff) for PD. I wonder if it could be hacked with [rpole~]...?

Hey OID i have read the article a year ago... You had posted this in the Karlsen thread. Should read it again a very nice article.

Bythe way in one hour the battle of the Filters begin
stay tuned!

@bocanegra Yeah, I know little of digital techniques, this is one of the few times I successfully moved something from the analog world to the digital, but the calculating of the ratios should be covered and will work.

@tungee I did not see that I posted it there, I had completely forgotten about that thread until it was posted in the [bob~] thread. But you can get all the mix ratio from my filter, the version in the first post is the simplest, no morph and much simpler, you should have no issues figuring that one out, all those message boxes are just the mix ratios for the 20 modes. I will probably have the resonance morph fixed by weeks end, just have not had the time to finish it up. As I said earlier, I do not do much audio work in pd, I just posted this so people would have it and the technique, so low priority for me.

The Battle of the Pure Data Filters has begun:

@tungee Oiderheim wins on name alone. That made me chuckle.

OId i wanted it name Matrixoid first

Just wanted to say this thread is tight and made me smile