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:
| [2200, 440( <--click here, several times!!
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?!