[PD] [bp~] really equal to [vcf~]?

Alexandros Drymonitis adrcki at gmail.com
Thu Jul 24 19:51:49 CEST 2014 

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 <porres at 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 <porres at 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 <msp at 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.off at 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 <
>>> porres at 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 <msp at 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 <msp at 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-list at iem.at mailing list
>>> > >>> > > > UNSUBSCRIBE and account-management ->
>>> > >>> > > http://lists.puredata.info/listinfo/pd-list
>>> > >>> > >
>>> > >>> > >
>>> > >>>
>>> > >>
>>> > >>
>>> > >> _______________________________________________
>>> > >> Pd-list at lists.iem.at mailing list
>>> > >>
>>> > >> UNSUBSCRIBE and account-management ->
>>> > >> http://lists.puredata.info/listinfo/pd-list
>>> > >>
>>> > >>
>>> > >
>>>
>>
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140724/4dbc77c2/attachment.html>

More information about the Pd-list mailing list