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

Nice! I had the same idea but didn't take it as far. The problem here (as far as I can tell) is that the feedback path will have a delay time = block size (in samples). I reckon setting block size to 1 inside [polemix~] would ameliorate this?

@bocanegra said:

I reckon setting block size to 1 inside [polemix~] would ameliorate this?

Would it? i use hardware for my audio and only dabble with it in pd, so I really do not know, primarily use pd for control. But I added it along with initial arguments and code clean up. Probably will futz with the resonance loop as well, could sound better and less like the resonance of almost every other digital filter. Will upload later. RE; stuff in the other thread, This does not seem to work with [vcf~]'s lowpass output, it does work with its bandpass but polemixing with bandpass filters is not exactly exciting. This is essentially the result I expected before I even started this, while pole mixing is trivial as you said, there is rarely a 1:1 relation between pd and the realworld in such matters and the things I do so simply with a soldering iron never quite work in pd. Nice surprise that it worked so well, if it was not for the eh resonance I would call it a good filter.

@oid It is quite awesome

Besides the resonance issue, being able to sweep your filter with signal envelopes is a nice thing so... Here is a suggested improvement: Redo the entire filter section as an abstraction with block size set to one and all inputs (sig, cutoff, resonance) as signals like this: 4ResPoles~.pd

The inlets are as mentioned before: Signal, Cut-off frequency in Hz, Resonance

One could inject sigmoids into each pole loop ([cos~] is cheap on CPU) for moogyness, but it would mess up the otherwise linear Hz to filter coefficient function- whether this this matters when you are doing a fast envelope on your moogy vcf is up to your ear though

@bocanegra Yeah, already started playing with adding signal rate, the first patch was just thrown together when i was supposed to be in bed and I had no intention of developing it further beyond a couple quick fixes, but once I started playing with it I had to improve it more. Your filter core seems to have less aliasing issues at high resonance but also a less controlled resonance and more sterile sound, but my comparison was quick and I have no idea how accurate. Mainly fighting with the resonance at this time, never found a way that I was happy with but I am nearing a compromise, not quite a traditional resonance sound but interesting a versatile and suits this filter. Thanks, for the filter.

@oid said:

Your filter core seems to have less aliasing issues at high resonance but also a less controlled resonance and more sterile sound

That would boil down to the clipping object I omitted. You could add it like this:

But hard clipping produces aliasing like you say, so some sort of sigmoid/soft clipping might be in order...

@bocanegra I tested it with the same resonance path as my current version, just dropped your core in place of mine and added a couple [sig~]s. The difference could be that my test was a quick and dirty cursory check and just me or that it is optimized for [lop~], will play more with it today.

Here's an observation: the resonance path in both our filters assumes a four stage LP ladder. When you are doing pole mixing the 4 stage 24db LP is just one out of 20+ possible combos. It sounds just right with the 0 0 0 0 1 mix, and ok with the other low pass mixes but not right (for 0 0 0 1 0 the feedback should be from the third low pass, not the fourth). And for allpass/phasers? Catch my drift? Perhaps the feedback should be taken from the final pole mix ?

Also, I found that introducing an averaging filter in the feedback path helps reduce artifacts, like so:

@bocanegra The problem with taking the resonance from the final mix is that then the resonance morphs as well so you loose some complexity in the sound of the morph and while it helps the resonance of some, it hurts others. In my current filter the resonance path has it's own morph between the two outputs, it is kind of nice and can do some fun tricks. The averaging filter is a nice edition. Think I am nearing completion, went back to [lop~], like its sound the best and the zipper noise can be worked around most of the time.

edit: better yet, second mix network so you can choose the filter response of the resonance separate. Some of the combinations yield little but some are quite great, 24db lp with a 12db notch resonance path is great.

New and improved. Now you can independently morph the resonance path and the filter is much less likely to experience full phase cancellation during morphing, still happens with some combinations but happens in a more interesting way when it does.


polemix2.zip

@oid It's getting better and better! The tanh soft clipper adds a nice grit to the sound

Is there a specific reason for setting the feedback delay to 10 samples? I would think 1 sample delay to be ideal?

I still prefer having signal rate frequency control. There are several ways to achieve this besides the filter I posted previously. The classic one pole low pass equation is y[n] = y[n-1] + a * (x[n] - y[n-1]). That was what I based my filter on (with a few tricks to minimize computation exploiting the fact that each filter should also be inverted). You could do this with [fexpr~] as well (and [rpole~] too).

Testing impulse response against [lop~] there is a slight difference (very tiny) in output amplitude, which I reckon is either because of difference in filter coefficient calculation or [lop~] gaining the outlet slightly as mentioned in H01.low.pass.pd: The lop~ object is normalized to pass DC (the lowest frequency) with a gain of one

However, looking at the source code for [lop~] ( https://github.com/pure-data/pure-data/blob/master/src/d_filter.c ) the coefficient is calculated the same way as I did it though: coef= F(Hz) * 2PI / samplerate. I can't seem to find any "normalizing" function, and the central filter equation is: y[n] = a*x[n] + (1-a)*y[n-1], essentially the same as y[n] = y[n-1] + a * (x[n] - y[n-1]).

Here are two [lop~] alternatives with signal rate frequency input for you to try out: Alternative_lop.zip

@bocanegra No idea how that 10 sample delay got in there, interesting that it found it's way to both the read and the write. As to the filters, I get a very noticeable difference, especially at high resonance settings, the phaser modes were indistinguishable from each other, unpleasant and sounded more like sweeping a single notch. Quick look over and no errors jump out at me, will play with it later and see what I can figure out.

A few test runs later...

Removing bias from the test signal helps reduce some of the worst squealing. [phasors~] output is from 0 to 1, and I imagine some bias can build up in the low pass chain and cause clipping on more extreme filter settings...

The averaging filter is wrongly implemented- both inlets on the [+~] are connected to the [rzero_rev~ 0]. Implementing it properly further reduces the high frequency squealing.

To remove further glitches, oversampling does the trick (we are getting CPU heavy here). Do [block~ 1 1 2] and behold! ([block~ 1 1 4] required for the custom lop~)

Fixing all this and comparing [polemix~] with vanilla [lop~] to [polemix~] with the custom [lop2~] side by side I hear zero difference. Try it out yourself: polefix.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.