Heya folks,

Iam using puredata vanilla to develope a mobile app with libpd. I dont use any externals from PD Extended,

Playing with the [lop~] [bp~] and [hip~] filter I recognized some strange behaviour. The lowpass is working well. But the highpass filter does not work for me. Filtering a [pink~] signal with [hip~ 20000] does not filter the signal like i would expect. Look at the following images illustrating the problem. Iam using a patch with 4 serial highpass filter with the same input frequency. Until 6000Hz everything is fine, but then things do not work as anticipated. Using a [noise~] instead of [pink~] makes the filter even more impractical.
Maybe Im totally wrong and thats the normal way it should work?

The Test Patch: hip-test.pd

0Hz Filter:
6000Hz Filter:
20000Hz Filter

Thanks in advance!

Edit: I have been playing around with the [bp~] filter and noticed some strange behaviour, too. Until 13kHz everything is working as expected. However cut-off frequencies above this value are not working anymore and the cut-off will still stay at 13kHz. The [vcf~] is working fine and it does what it is meant to do.

Yes, wait for that. And thank you, in advance.

Hello all,

I reported these bugs in pd-vanilla in our mailing list, and if I hear any feedback about it I post it back here.

Take care,
Gilberto

Hi all,

According to our mailing list, these problems are not exactly "bugs" but rather limitation of these two filters: basically they were not designed to be used for such high frequencies. So if you'd need to deal with something higher than ~12 kHz, it's better to use other filters, such as [vcf~].

If anyone is interested, this is the thread in the mailing list: https://www.mail-archive.com/pd-list@lists.iem.at/msg02169.html

Take care,
Gilberto

Good job, thank you.

Maybe Alexandre Torres Porres is right, since the numbers at which the filters stop responding seem to be "designer numbers".

But there are still some things left to be explained. When I did a test using 4 high pass filters in a serial manner, things didn't go as expected. (@pduser42 was doing serial stuff).

Anyway, we can accept their limitations, use vcf~, make some combinations, or use the various Pd extended filters. Knowing the pros and cons of your tools is a good thing.

@LandonPD

Maybe Alexandre Torres Porres is right, since the numbers at which the filters stop responding seem to be "designer numbers".

Indeed they are suspicious numbers, so this seems to be true.

But there are still some things left to be explained. When I did a test using 4 high pass filters in a serial manner, things didn't go as expected

What exactly was the problem?

Anyway, we can accept their limitations

Yes, but I find this a bit annoying since [hip~], [lop~] and [bd~] are the first filters a beginner in Pd learns to use (virtually all tutorials use them). It's like having better tools that are also a bit hidden, or even worse, nobody knows that they are better. In the lower part of the spectrum, [vcf~] and [bd~] are virtually indistinguishable.

And one more thing: someone in the list also recommended [iemlib/hp1~], which is a much better high pass filter that works with any frequency. If I would have any saying in this all, I would just replace [hip~] for it and call it "problem solved"...

Take care,
Gilberto

@gsagostinho

"What exactly was the problem?"

The problem was this: 4 high pass filters in series didn't reduce the level of the stop band any further when compared to a single filter. In fact, the signal increased in overall level. Anyway, since it was a quick rough test, I could be wrong .

"I find this a bit annoying".

Yes, me too. Miller has a saying for this, when he finds a bug or limitation he doesn't like: you get what you pay for!

@LandonPD

I see. The problem is that the original high pass filter is not being consistent with the amplitude, it actually raises the amplitude of some parts of the spectrum (!), and when you connect them in series the effect is multiplied. I haven't tried doing the same with [iemlib/hp1~], but I bet it will work perfectly well, since it behaves as a proper filter does: -3dB at the cut-off frequency, and no amplification of ANY part of the original spectrum.

Miller has a saying for this, when he finds a bug or limitation he doesn't like: you get what you pay for!

Nothing irritates me more than this quote, and it is disheartening to hear it from an open source developer... that is the motto (or rather mantra) of all executives that brush Linux and open source projects off. I understand the context he says this, but still...

That explanation is probably on the right track.

I was not reading this for a few weeks. However I read the mailing list and the answers here and I'm a bit shocked that there are some "magical" numbers limiting the filters. It's even more weird that that numbers are not documented anywhere. Why is the [lop~] not limited?

Something practical to find a workaround:
Edit: Okay I found the patch from Katja Vetter in the Mailing list. That one is working.
I would like to use a sawtooth or square oscillator (many harmonics) in combination with a highpass filter to create a simple timbre effect. Using the limited [hip~] does not quite down the sound at all. So is it possible to build a "working" [hip~] alternative using PD-Vanilla only? Patch any one?

Thanks in advance!

@pduser42 Yes, I feel pretty much the same as you do.

One solution is to use those filters from the mailing list, and the other is to copy [iemlib/hp1~] from a pd-extended installation (I can send you the Linux 64-bit one if that helps you). I did so and it works flawlessly with pd vanilla.

Take care,
Gilberto

I 'm not really an expert on filter mathematics at all, but I tested the impulse response of the mentioned filters. [bp~] is actually quite shocking as it doubles the gain at high frequencies! [vcf~] is also not so impressive. The IEM-filters work as expected, though, and I guess I'll use them more in the future . For comparison I build a 1 pole 1 zero high pass using pd's raw filters and I got the exact same result as with [hp1] from iemlib.
I actually have a possible explanation for the "weird" frequency response of pd's [hip~]: The overall behaviour is that of a 1 pole 1 zero high pass filter, but it looks like Miller used another formular to calculate the filter coefficient from the cutoff frequency. The frequency response gets more and more "behind" for higher cutoff frequencies and eventually the pole stops at 0 at 7000 Hz (which is weird!). What is left is the zero at 1 , thus the filter freezes at the frequency response of a 1 pole 1 zero high pass at 1/2 nyquist (11025).
The "real" formula for the filter coefficient based on the cutoff frequency, however, is: p = (1 - sin(x))/cos(x) (where x is the frequency in radians). Here p goes all the way from 1 to -1 over course of 0 - nyquist. At the nyqist the output of the filter is 0 as you would expect.
As Miller writes in the help file, [hip~] is primarily meant to be used for DC removal and it does its job fine. But there should be warnings in the helpfiles of [hip~], [bp~] and [vcf~]

BTW, here's the "correct" 1 pole 1 zero highpass filter:

#N canvas 0 50 450 300 10;
#X obj 40 63 inlet~;
#X obj 49 238 outlet~;
#X obj 139 31 inlet~;
#X obj 50 209 rpole~;
#X obj 48 140 *~;
#X obj 141 69 /~;
#X obj 206 69 samplerate~;
#X obj 205 31 loadbang;
#X obj 143 166 +~ 1;
#X obj 149 189 *~ 0.5;
#X obj 49 177 rzero~ 1;
#X obj 138 132 expr~ (1-sin($v1))/cos($v1);
#X obj 134 102 *~ 6.28319;
#X connect 0 0 4 0;
#X connect 2 0 5 0;
#X connect 3 0 1 0;
#X connect 4 0 10 0;
#X connect 5 0 12 0;
#X connect 6 0 5 1;
#X connect 7 0 6 0;
#X connect 8 0 9 0;
#X connect 9 0 4 1;
#X connect 10 0 3 0;
#X connect 11 0 3 1;
#X connect 11 0 8 0;
#X connect 12 0 11 0;