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.

Hello again,

I tested this case using some independent computers with different configurations and one mac.

First windows pc: Bandpass and highpass does not work.
Second windows pc: works fine
Third windows pc: Does not work
Mac: Works fine

Update:
I sorted out, what was going wrong: Using the zipball of PureData Vanilla does not produce failures on any of the tested systems. So it seems like a bug in the PureData-Extended Installation.

Hi,

I can confirm I have the exact same behaviour as you describe when using pd extended on Linux. So you are saying that the same objects [bp~] and [hip~] work differently when using Pd vanilla (that is, they behave as expected without the bugs we are experiencing with Pd extended)?

Thanks for the post and take care,
Gilberto

To what versions of extended and vanilla are you referring? This may have been a bug that already got fixed in vanilla

@seb-harmonik.ar Hi seb, my extended is version 0.43.4.

Take care,
Gilberto

Thanks for the confirmation.

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

I will report this bug to the PD-Extended Devs.

FYI: http://sourceforge.net/p/pure-data/bugs/1187/

@pduser42 wrote:

I will report this bug to the PD-Extended Devs.

That would be very nice, thanks for reporting it! Let me know if you need any more information about the bug.

Take care,
Gilberto

FYI: http://sourceforge.net/p/pure-data/bugs/1187/

Thanks a lot!

NOTE: This bug is also present in Pd-l2Ork for Linux, and I already warned the devs about it.

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

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.