No problem, Joe. I took everything from the canonical RBJ source: http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt
I didn't do the shelving because they are a pain in ass to do using expr. I should mention that these calculate the bandwidth of the filter and not Q. I find it easier for bandpass and peaking EQ to use bw, but to have resonance for a hi/lopass filter the values need to be low ( bw < 1). The abstractions should include the expr to do Q just not hooked up. Chris On Fri, May 23, 2014 at 7:06 AM, Joe White <white.j...@gmail.com> wrote: > Thanks for the abstractions Chris. Am I correct in thinking the licensing > issues for [expr] have been resolved now? > > Cheers, > Joe > > > On 21 May 2014 23:22, Chris Clepper <cgclep...@gmail.com> wrote: > >> On Wed, May 21, 2014 at 5:31 PM, Joe White <white.j...@gmail.com> wrote: >> >>> >>> >>> Is it intentional to not a bank of go-to filters? [biquad~] is the next >>> one I would go to, but generating your own coefficients isn't that... err.. >>> efficient when you're wanting some that just 'works' :) >>> >>> >> Attached are a set of abstractions wrapping most of the 'Audio EQ >> Cookbook' formulae around biquad~. It would be nice for Pd to include >> something like this. >> >> The only drawback to [biquad~] is it doesn't take audio rate >> coefficients. There are of course externals that do audio rate for cutoff, >> Q, etc. >> >> Chris >> >> >>> >>> >>> On 21 May 2014 17:31, Miller Puckette <m...@ucsd.edu> wrote: >>> >>>> Hi Joe - >>>> >>>> That code is an approximation that works well for low cutoff >>>> frequencies but badly for high ones. (I should probably warn >>>> about this in the help window... that'll go on my dolist) >>>> >>>> cheers >>>> M >>>> >>>> >>>> On Fri, May 16, 2014 at 12:58:31PM +0100, Joe White wrote: >>>> > Hi, >>>> > >>>> > I've been looking at the [lop~] implementation (Pd-0.45-4) and noticed >>>> > something that seem weird to me. >>>> > >>>> > In d_filter, line 176: >>>> > >>>> > static void siglop_ft1(t_siglop *x, t_floatarg f) >>>> > { >>>> > if (f < 0) f = 0; >>>> > x->x_hz = f; >>>> > x->x_ctl->c_coef = f * (2 * 3.14159) / x->x_sr; >>>> > if (x->x_ctl->c_coef > 1) >>>> > x->x_ctl->c_coef = 1; >>>> > else if (x->x_ctl->c_coef < 0) >>>> > x->x_ctl->c_coef = 0; >>>> > } >>>> > >>>> > >>>> > Is it correct that for: >>>> > >>>> > y[n] = x[n] * a + y[n-1] * b >>>> > >>>> > *a = 2π * Fc / Fs* >>>> > b = 1.0 - a >>>> > >>>> > where Fc is the cut-off frequency and Fs the sampling frequency. >>>> > >>>> > I appreciate the a coefficient is bounded afterwards but wouldn't >>>> that mean >>>> > that Fc values greater than Fs / 2π will have no impact on the sound >>>> being >>>> > processed. >>>> > >>>> > For example if Fs is 44100, then Fc values above ~7020Hz will not >>>> affect >>>> > the filter. >>>> > >>>> > Have I missed something crucial or could this a bug in the code? >>>> > >>>> > The simple IIR filter described in >>>> > http://en.wikipedia.org/wiki/Low-pass_filter suggests that the actual >>>> > coefficient calculation should be more like: >>>> > >>>> > a = 2π*Fc / (2π*Fc + Fs) >>>> > >>>> > Looking forward to understand this more! >>>> > >>>> > Cheers, >>>> > Joe >>>> > >>>> > -- >>>> > Follow me on Twitter @diplojocus >>>> >>>> > _______________________________________________ >>>> > Pd-list@lists.iem.at mailing list >>>> > UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>> >>> >>> -- >>> Follow me on Twitter @diplojocus >>> >>> _______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> > > > -- > Follow me on Twitter @diplojocus >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list