Hello everyone,
here is another buggy thing (rather an object..)

Iemlibs [filter~] object seems to have some strange behavior...
(Note that it is included with the [ap1~], [ap2~], [lp1~], etc. )

Does anyone know if there are still some known problems with this object???

((First of all, but thats not the actual bug, I noticed that the [filter~]'s ap2-mode in some situation (it didn't do in my test-patch...??!!?!?) outputs just waste when used in a [block~ 8 1 1]-ed patch. It works with [block~ 4], it works with [block~ 16], but only not with the [block~ 8 1 1]. The only thing I can see is that 8^2 = 64 <-It's the default blocksize...however, can this be the reason???))

Well now the actual, reproducible BUG:
Just try this:

[phasor~ 440]
|
| [2200, 440( <--click here, several times!!
| |
[lp1~]
|\
[output~]

It changes its state from the first (=2200) to the last (=440) on every click!!! That shouldn't be, should it?
Vanilla-filters like [lop~], [hip~] or [bp~] just use the last received value for audio-interactions! (that would be the "440" Hz as the filter-freq.)

There must be some-kind-of-internal-scheduling-action-stuff
What do you think??

...there are no (vanilla)-alternatives for the [ap1~] and [ap2~], is this true?!?

And one last thing:
There are filter-types like "lp1", "lp1c", "dlp1" or "bpq2" and "rbpq2"
Does anyone know what these -c, d-, or r- suf-& prefixes mean?!

Bye Flipp

There was a bug a while ago with the iem filters in which the interpolation didn't work properly. Instead of being smoothly updated, it would only update at the block boundaries, which sounded terrible. I can't seem to make it happen again, so maybe it was fixed. But I'm guessing this issue is related.

As far as the prefixes and suffixes, look at the top of the help files.

Thanks Maelstorm,
At least now I know that the "-c" (in eg [lp1c~]) stands for cascade, and actually the wrapper-abstraction for the [filter~] differs from the normal ones (like [lp1~]).
But [filter~]'s filter-mode reads "lp1c" as well, so what's the difference in [filter~]'s internal operation, as well as with "dlp1"-filter-mode, there even is no helpfile cause there is no wrapper (like eg [dlp1~])..
And apparently there is no help for the [filter~] itself, as well.

If I just set an interpolation-time of 1000 ms the filter, "on click", smoothly fades between the values given in the message, instead of jumping...

I think [filter~] is just meant to be an "all-purpose" external that is designed for the wrappers, which is why there is no helpfile for it. dlp1 is for double-precision, which I believe means it uses 64-bit values internally for calculation before converting them to 32-bit floats on output.

I'm not sure what you're asking about lp1c, though.

uh, double-precision, that's cool.
I was looking for some more precision here and there anyways.
Btw. is there a way to get a higher precision out of pd in general (for rendering-purposes etc)??
The objects don't even use 32bit externally, do they?? (I don't mean the objects internal calculus)

Lets just look at the [filter~] : whats the difference between "lp1"-mode and "lp1c"-mode ("dlp1"-mode => "double precision lp" as I just learned )

Ah, I see. Well, I can't say for sure what the difference is specifically with the implementation of the two modes. But I can explain why they're there. Basically, with higher order filters calculating the coefficients can be a bit unwieldy. So, it is often easier and more manageable to break it up into smaller filters running in series (cascaded). In fact, the generalized formula for normalized Butterworth filters of any order represents it as a series of 2nd-order filters, plus a single 1st-order filter if it is an odd order. So the design itself is easier that way, in that it's already broken up for you.

As for getting higher precision in Pd, you would need to use a version that is specifically built for it. Pd has been a bit behind on getting to 64-bit. 64-bit builds for 0.43 based on katjav's code were just added the other day:

http://puredata.info/Members/hans/double-precision-pd-builds

tring to keep up with the builds is kind of easy

8 ( its not for windows ?

A 64 bit biquad would be very nice, since biquads get very noisy for low frequencies and high sample rates...

@Maelstorm said:

As for getting higher precision in Pd, you would need to use a version that is specifically built for it. Pd has been a bit behind on getting to 64-bit. 64-bit builds for 0.43 based on katjav's code were just added the other day

Yes, Pd has been a bit behind on double precision, but Hans has been a bit fast to announce double precision nightly builds of Pd-extended. These builds fail or fail partly at the moment.

In fact, the only part made ready for double precision is this fork of vanilla Pd:

https://github.com/pd-projects/pd-double

You can compile your own double precision vanilla Pd from this code. It would be nice to have binaries uploaded somewhere, I'll check if that is possible.

Also note that '64-bit build' does not refer to floating point precision, but to pointer size and addressable memory space.

Katja

I'm looking forward to using this... hmmm "scientific precision"...
Just to make shure.., will it run on every windows, if it works at all??