You will see Acceleration make two little nodes (similar to Average) where it does it's thing: One at the sample rate and one at half the sample rate. I don't think the algorithm says "Let's filter frequency X, depending on sample rate" - it won't even kick in unless a certain waveform criteria is met (the zig/zag/zig Chris mentions).

I suspect that the algorithm is actually the same at any sample rate, but the difference in performance of the plugin at different sample rates is actually because the material itself that you are feeding it is different.

**I'm liable to be wrong about these things**, of course, but here goes:

Imagine taking a bucket of 4 x 4-sized lego bricks. Try making a really rounded, smooth, and curvey "wave" shape with those lego bricks. Now, remeber that all the bricks are 4 x 4-sized. So you can imagine, the bigger the wave, the more accurately we can represent it using 4 x 4-sized blocks. Very fast and thin waves present the biggest challenge to represent. The fastest wave might be so fine that all we can do is use a single 4 x 4 brick to represent something that's supposed to be round and smooth.

The lego is your digital audio bits, and the wave you are reconstructing is that of your audio. This is my crappy and likely flawed analogy for digital audio sample encoding.

It's hard enough to make singular waves out of lego blocks. Now try to make a whole sea front. Big waves made of lego look great, small ones look harsh and jagged, and probably at best are just a rough approximation. The bigger waves = lower frequency and the smaller ones = higher frequencies. Stand back and look at the picture you made of lego - it should still resemble the source, but the resolution is non-linear with frequency.

Now try again, but using smaller 2 x 2 blocks.... Those smaller waves are now twice as accurate, but it takes twice the effort to produce.

Keep in mind that the sample rate is basically "the highest frequency to be sampled". Therefore, at 44100hz sample rate, you're going to start running out of resolution in the highs much sooner than if you run 96000hz.

My thinking is this: Where things start to get more and more innacurate, right around the sample rate frequency (and also at half of that), is where you're more and more likely to get that "zig/zag/zig" behaviour, because for example the sharper edges on the waves up there. Hence, you start to see Acceleration kick in at the sample rate and also at half the sample rate, resembling Chris's Average filter when it's criteria is met.

If any of that is anywhere near the truth, it means that the algorithm does not change at different sample rates. The difference is the sample rate of the material that you feed into it. And it's got me wondering if there's any potential for using this algorithm to fight aliasing....?

Heck, whether any of this post is accurate or not, I've become so addicted to this that I'm really falling out of love with normal EQ. Here's hoping we get to see more adventures in state-variable filtering