Ahhh.... cool :)
On 23 May 2014 13:12, i go bananas <hard....@gmail.com> wrote: > as far as i know, [expr] went from charcoal to grey, didn't it? > > > On Fri, May 23, 2014 at 8:06 PM, 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 >> >> > -- Follow me on Twitter @diplojocus
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list