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.

... btw this is a bit OT but just so everyone knows work on pd-extended is halted because no one is currently working on it so it might be quite a while before changes from vanilla make it into extended. Regardless, the changes from pd-vanilla (e.g. the bug that is fixed) will be merged into pd-extended if/when someone does work on it

@seb-harmonik.ar Yeah, that's totally true, thanks for the info, Seb. There were also some talks recently in the mailing list concerning pd-extended - I think the idea would be to check, update, reorganize and release those libraries from extended as packages that could be downloaded and installed in vanilla, if I understood it correctly - but it seems that topic died out and went nowhere

On the other hand, I believe the guys from l2Ork distribution will most certainly have a look on it and fix it.

Take care,
Gilberto

@pduser42

Bugged PD-Extended Version: 0.43.4
Working PD-Vanilla Version: 0.45.4

Are you sure this is working with Pd-Vanilla 0.45.4? I just compiled it and made some tests, and I have the exact same behaviour as with extended and l2ork! Would you mind trying this patch of mine below and telling me if the results are the same as in the video below? I'd really appreciate the help.

filter-test.pd

Note: I am using [multiplex~] in this patch above, and I included the Linux external only (I copied it from the Linux installation of pd-extended in my computer). Since I know you are on Windows, could you please copy the file multiplex~ from the folder C:\Program Files\pd-extended\extra\zexy to the same place as my patch above, or alternatively you can just skip it and connect one filter at a time directly to [spectrogram~]? If you need any help with this, let me know.

Thanks a lot and take care,
Gilberto

I also tested this patch with vanilla 0.46.5 and the same problem exists there. It makes me think that the bugs with these filters were not corrected at all.

Now I see why some of the things I tried to do, not so long ago, didn't work completely as I had expected!

On WinXP, using a different analyzer than above, I observe that bp~ peaks exactly at 12000 Hz, and doesn't respond beyond that.

And, in the case of hip~, the filter seems to stop responding from 6000 Hz upwards, but in a weird way.

@LandonPD

Thanks for the reply Landon. Are you using vanilla or extended? If this is confirmed to be present in vanilla (as I am suspecting now), I will report it to Miller.

Take care,
Gilberto

Oops, sorry, it's 0.43.4-extended. I'm sure Miller will quickly put this into his "dolist" (sic), as he calls it.

@LandonPD Ok thanks a lot, Landon. Before I send this to Miller, I just want to wait for pduser42 to reply since he mentioned that this was working on his vanilla install, and I want to confirm if that was a mistake or what.

Take care,
Gilberto

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~]