I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external.
Is it possible to convert the Moogladder opcode to a Pd abstraction?
Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32
/Anton
Anton Hörnquist wrote:
I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external.
Is it possible to convert the Moogladder opcode to a Pd abstraction?
Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32
It should be possible to make an external with that. I could give it a go, but there's already an extern [moog~] in ggee of the pd-extended. Is that not the same?
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Anton H?rnquist wrote:
I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external.
Is it possible to convert the Moogladder opcode to a Pd abstraction?
Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32
It should be possible to make an external with that. I could give it a go, but there's already an extern [moog~] in ggee of the pd-extended. Is that not the same?
I think [moog~] follows the older Stilson/J.O.Smith model of the moog filter from 1996, while the moogladder opcode is an implementation of a later publication from 2004: http://dafx04.na.infn.it/WebProc/Proc/P_061.pdf
I think, it may also be possible to implement it as a pure Pd abstraction with some stacked [rpole~]s and fine tuning, as from a quick look it seems to be just a bunch of first order filters with tanh()-distorted filter coefficients. But quick looks may be deceiving ...
Frank
Frank Barknecht wrote:
I think, it may also be possible to implement it as a pure Pd abstraction with some stacked [rpole~]s and fine tuning, as from a quick look it seems to be just a bunch of first order filters with tanh()-distorted filter coefficients. But quick looks may be deceiving ...
You have been deceived, the filter has the tanh()s inside the recursive loops, so it's not a linear filter.
Claude
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
Frank Barknecht wrote:
I think, it may also be possible to implement it as a pure Pd abstraction with some stacked [rpole~]s and fine tuning, as from a quick look it seems to be just a bunch of first order filters with tanh()-distorted filter coefficients. But quick looks may be deceiving ...
You have been deceived, the filter has the tanh()s inside the recursive loops, so it's not a linear filter.
I'm deceived too easily. ;)
To make up for my mistake, I did a quick port of Victor's CSound code to a Pd external here: http://footils.org/pkg/moogladder-0.1.tgz
It's just a quick copy-and-paste version, not really tested, so expect bugs and be careful with the volume! The makefile only has a pd_linux target, but it may be a start if someone wants to take over. Possible enhancements could include signal inlets for frequency and resonance instead of float inlets and maybe table lookup for the tanh-calculation instead of direct computation.
Frank Barknecht