Alexandre Torres Porres
porres at gmail.com
Wed Dec 31 23:11:40 CET 2014
> Miller (being the author) would know better
But the [moog~] object that I see here on Pd extended was written by gunter
> it would be super cool to have this as a Pd
> abstraction rather than an extern.
Dan Wilcox also wanted that as I remember. If you care to help me we could
try and do it. I kinda suck at math and all but when I put my mind into it
I can do these things I never knew I could :) I've been implementing
several filters with [fexpr~] and/or vanilla's raw pole/zero filters. I've
kinda done them all, [moog~] is the next on my list.
But I probably won't get into this until the 2nd half of january, as I plan
to go to some island for my summer break.
cheers and happy new year.
2014-12-31 19:42 GMT-02:00 David Medine <dmedine at ucsd.edu>:
> Cool, I will definitely check out this SC object. Thanks for that.
> Miller (being the author) would know better than I of course, but I
> believe the way that [moog~] works is to use Runge-Kutta to solve the
> ordinary differential equation that governs each stage of the filter in its
> continuous time representation. This equation (along with a discrete
> implementation of the complete filter) is what is described in the paper I
> mentioned. Incidentally, using Runge-Kutta (or any appropriate iterative
> ODE solver) also abnegates the frequency warping problem.
> I think it might be very difficult to code this up with [fexpr~]. It would
> certainly require at least a quadrupling of the sampling rate. Has anyone
> out there ever implemented Runge-Kutta with [expr~]? It might also be that
> Pd's data structures are an appropriate choice for such a project? Either
> way, it would be super cool to have this as a Pd abstraction rather than an
> On 12/31/2014 10:05 AM, Alexandre Torres Porres wrote:
> Hi David,
> > It'd certainly be interesting to see an what actual implementation
> > of this does, rather than just some matlab plots.
> An actual implementation is provided in the MoogFF filter in Super
> Collider, you can just download and try it out. The code of the object is
> also provided somewhere, as it is a source code.
> I'd like to understand pd's [moog~] object one day, and implement it
> with [fexpr~] or something. Maybe I'll do this other one as well.
> 2014-12-29 17:20 GMT-02:00 David Medine <dmedine at ucsd.edu>:
>> I believe, though I may be wrong, that the Moog vcf object is based on
>> the algorithm described in the 2004 Huovalainen paper (citation  in the
>> I am a little confused here (in the Fontana) by the author's assertion
>> that he can implement a 'delay-free' loop by computing the output first,
>> and then finding the states of the filter based on this. I don't quite see
>> how this is different from finding the states first and then finding the
>> output -- chicken then the egg vs. egg then the chicken.
>> Still, judging by the plots they provide, they seem to have overcome the
>> frequency warping issue (an artifact of unit delay) described by
>> It'd certainly be interesting to see an what actual implementation of
>> this does, rather than just some matlab plots.
>> On 12/28/2014 07:43 PM, Alexandre Torres Porres wrote:
>> hi, do you know if the moog object comes from this paper?
>> _______________________________________________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 ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list