Since there's been quite some discussion on this subject, I'll bump in to share eight externals I wrote, based on Mike Moser-Booth's (mmb) [flitercoeff.mmb~] and [biquad.mmb~] abstractions. The objects are: [lowPass~], [bandPass~], [highPass~], [allPass~], [resonant~], [lowShelf~], [peakNotch~] and [highShelf~]. They all have only signal inlets to avoid clicks when changing parameters. You can get them here http://drymonitis.me/code/ look for the "Various filters" link. The .zip file contains binaries for OS X and Linux, help patches (dunno if they are very helpful), source code, Pd's generic Makefile and a README. Comments are welcome.
On Thu, Jul 24, 2014 at 8:40 PM, Alexandre Torres Porres <por...@gmail.com> wrote: > > whether a [cpole~] filter like [vcf~] could be obtained with [biquad~]. > > I meant at least the real output of [vcf~] > > > 2014-07-24 14:28 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > > yep, totally makes perfect sense to me now that it is a [cpole~]. >> >> I guess you can consider (ampcorrect * oneminusr) as a gain factor and >> multiply the input signal by this much before getting it to a [cpole~] with >> the same coefficients, and voilá... although getting all these >> coefficients to come up in a vanilla patch seems a lot of trouble... >> >> But what I'm really and still dying to learn/figure out is whether a >> [cpole~] filter like [vcf~] could be obtained with [biquad~]. My intuition >> said: Yes. But after a few experiments I'm changing my mind... Can anyone >> just confirm me that? >> >> What drove my intuition is the attached patch, which is a biquad~ filter >> made of raw filters I derived from mmb's work. If it made any sense is >> because it is implemented with [cpole~] and [czero~] objects, so it seemed >> that a set of biquad coefficients could result in just a couple of >> coefficients for one [cpole~]. But then, by checking it out and trying to >> do it, it doens't seem possible to get a coordinate pair for a [cpole~] >> with biquad coefficients... hmmm, bummer. >> >> Any thoughts? >> >> thanks >> >> >> 2014-07-24 13:33 GMT-03:00 Miller Puckette <m...@ucsd.edu>: >> >> Yep, vcf~ isn't a 2-pole real filter but a 1-pole complex one (although >>> its second outlet -- I think -- should be similar to a 2-pole real >>> filter's output in theory, but in reality should be numerically more >>> precise.) >>> >>> I'll change the comment to something vaguer and more descriptive in the >>> code.. >>> >>> Unless I'm badly mistaken, vcf~ is simply a cpole~ with extra stuff to >>> compute >>> the coefficient built in. There's no 'x2' because the input is taken to >>> be >>> real-valued. >>> >>> cheers >>> M >>> >>> On Thu, Jul 24, 2014 at 01:18:28PM -0300, Alexandre Torres Porres wrote: >>> > >> The real part may be used as a resonant >>> > >> bandpass filter and the imaginary as a >>> > >> resonant low-pass filter, but they can be >>> > >> combined to make other possibilities." >>> > >>> > > what sort of possibilities??? >>> > >>> > I wouldn't expect much about this. I guess it's like any other filters >>> that >>> > can be combined in many ways. >>> > >>> > Another thing I wanted to inquire is about bp~ having a frequency >>> response >>> > that is not symmetric. The lower part of the spectrum has more energy. >>> > Could one consider it more of a "resonant low-pass filter", similar to >>> > [vcf~]'s second outlet? >>> > >>> > By the way, while we're at it, I'd like to share something that may >>> not be >>> > too important, but it's related. I was able to implement [cpole~] in >>> > [fexpr~]. Here it goes: >>> > >>> > expr 1: >>> > >>> > [fexpr~ $x1 + ($x3 * $y1) - ($x4 * $y2); >>> > $x2 + ($x4 * $y1) + ($x3 * $y2)] >>> > >>> > if we consider $x3 and $x4 as variables named, respectively, coefr >>> > (coeficient for the real part) and coefi (coeficient for the imaginary >>> > part), we then have: >>> > >>> > expr 2: >>> > >>> > *[fexpr~ $x1 + (coefr * $y1) - (coefi * $y2);* >>> > *$x2** + (*coefi * $y1) + (coefr * $y2)] >>> > >>> > Now, by checking the code of [vcf~] I was able to narrow down to its >>> core >>> > formula, which is something like this >>> > >>> > expr 3: >>> > >>> > *ampcorrect * oneminusr* * *f1 + (coefr * re2) - (coefi * im)*; >>> > *(coefi * re2) + (coefr * im)* >>> > >>> > the bolded letters in "expr 3" seem to match perfectly to "expr 2". The >>> > differences are underlined ($x2 in expr 2 and ampcorrect/oneminusr in >>> expr >>> > 3). >>> > >>> > That gets me closer to being able to implement [vcf~] with a [cpole~] I >>> > guess, but I find it weird that the imaginary output does not have the >>> $x2 >>> > signal input to be added to the rest of the expression. I worry that >>> > actually prevents it from being successfully implemented with >>> [cpole~]. Am >>> > I missing something? >>> > >>> > Anyway, the thing is that I'm still really curious to learn wether >>> vcf~ is >>> > a "two pole" filter or a "one complex pole" filter, and the reason >>> behind >>> > it is because I believe we could make a biquad~ version of [vcf~] (at >>> least >>> > for its real output). That's the bottom line. >>> > >>> > cheers >>> > >>> > >>> > >>> > >>> > 2014-07-24 6:45 GMT-03:00 i go bananas <hard....@gmail.com>: >>> > >>> > > just chipping in with my 2 cents that it would be fantastic to get >>> more >>> > > documented info on all this. >>> > > >>> > > especially curious about: "but they can be combined to make other >>> > > possibilities." >>> > > >>> > > what sort of possibilities??? >>> > > >>> > > >>> > > On Thu, Jul 24, 2014 at 5:07 PM, Alexandre Torres Porres < >>> por...@gmail.com >>> > > > wrote: >>> > > >>> > >> Hi Miller, still trying to get my head around this. But anyway, one >>> thing >>> > >> I have to note is that the source code of [vcf~] says it is a "two >>> pole >>> > >> filter", not a "one complex pole" filter. >>> > >> >>> > >> Should that description be changed? If not, why? >>> > >> >>> > >> thanks >>> > >> >>> > >> >>> > >> 2014-04-12 14:13 GMT-03:00 Miller Puckette <m...@ucsd.edu>: >>> > >> >>> > >> Yep - vcf~ is essentially a wrapper for cpole~. >>> > >>> >>> > >>> cheers >>> > >>> M >>> > >>> >>> > >>> On Sat, Apr 12, 2014 at 02:10:19PM -0300, Alexandre Torres Porres >>> wrote: >>> > >>> > that's great to know, thanks! >>> > >>> > >>> > >>> > Let me just see if I get a bit of the theory. Can I get [vcf~] >>> with >>> > >>> just >>> > >>> > one [cpole~] object and the right coeficients? >>> > >>> > >>> > >>> > Cheers >>> > >>> > >>> > >>> > >>> > >>> > 2014-04-12 13:36 GMT-03:00 Miller Puckette <m...@ucsd.edu>: >>> > >>> > >>> > >>> > > They're quite different. bp~ is the cheapest possible bandpass >>> > >>> filter >>> > >>> > > (as far as I know). vcf~ is a one-pole complex filter whose >>> outputs >>> > >>> are >>> > >>> > > the real and imaginry parts. The real part may be used as a >>> resonant >>> > >>> > > bandpass filter and the imaginary as a resonant low-pass >>> filter, but >>> > >>> > > they can be combined to make other possibilities. >>> > >>> > > >>> > >>> > > It's possible to graph their frequency responses using the >>> help patch >>> > >>> > > "H10.measurement.pd' in 3.audio.examples. >>> > >>> > > >>> > >>> > > cheers >>> > >>> > > Miller >>> > >>> > > >>> > >>> > > On Sat, Apr 12, 2014 at 04:28:11AM -0300, Alexandre Torres >>> Porres >>> > >>> wrote: >>> > >>> > > > Hi there, who can confirm that both [bp~] and [vcf~] are >>> exactly >>> > >>> the >>> > >>> > > really >>> > >>> > > > same thingy? The code looks quite different... >>> > >>> > > > >>> > >>> > > > Moreover, why the two outlets for vcf~? Help doesn't say >>> anything. >>> > >>> > > > >>> > >>> > > > Thanks >>> > >>> > > >>> > >>> > > > _______________________________________________ >>> > >>> > > > pd-l...@iem.at mailing list >>> > >>> > > > UNSUBSCRIBE and account-management -> >>> > >>> > > http://lists.puredata.info/listinfo/pd-list >>> > >>> > > >>> > >>> > > >>> > >>> >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> Pd-list@lists.iem.at mailing list >>> > >> >>> > >> UNSUBSCRIBE and account-management -> >>> > >> http://lists.puredata.info/listinfo/pd-list >>> > >> >>> > >> >>> > > >>> >> >> > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list