[PD] Csound opcode Moogladder to Pd
I now made a version where cutoff and resonance are signals. This version is a bit more CPU intensive now, as some computations had to move into the DSP loop to react to the changes in center frequency. Awesome! To my ears it sounds great - very close to the Csound-version. I played a bit with a rational tanh approximation from the music-dsp list but it didn't sound good anymore. If someone wants to play with other approximations e.g. table lookup: Just change the function mytanh. Some optimizations are needed for reducing cpu load, true, I'll look into it. The filter response gets nasty and loud if the center frequency is near or above the sampling rate. Maybe it should be restricted as well. But then, resonance at 1 will make everyone jump, too... Yeah I noticed that aswell. I think the Csound-version has cutoff restricted to 0...1, which is 0...11050 in hertz. Thanks again. /Anton ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd
Hallo, Anton H?rnquist hat gesagt: // Anton H?rnquist wrote: The filter response gets nasty and loud if the center frequency is near or above the sampling rate. Maybe it should be restricted as well. But then, resonance at 1 will make everyone jump, too... Yeah I noticed that aswell. I think the Csound-version has cutoff restricted to 0...1, which is 0...11050 in hertz. Only resonance is restricted to 0 and 1. It is in the pd version as well. I made some tests now and it seems it's not the cutoff frequency alone that makes the filter run wild. With resonance set to 0 a cutoff of 96kHz when running at SR = 48kHz doesn't go wild. But set resonance to 0.1 and it runs away. So in the end I'd say, just be careful and if in doubt [clip~] your input values. Another issue may be denormalization, so some PD_BIG_OR_SMALL checks could be useful. Ciao -- Frank Barknecht ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: Here is a dll of Frank's moogladder~ v.02 compiled against pd 0.40_2 The code should go in svn somewhere. ( I replaced 2*M_PI in the code with TWO_PI to avoid a multiply (compiler optimisation maybe does that already)). Did you define that yourself? My math.h doesn't have TWO_PI ... Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Frank Barknecht wrote: ( I replaced 2*M_PI in the code with TWO_PI to avoid a multiply (compiler optimisation maybe does that already)). Did you define that yourself? My math.h doesn't have TWO_PI ... depending on compiler options, my math.h doesn't have M_PI ... http://c-faq.com/fp/mpi.html Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Anton Hörnquist wrote: Here is a dll of Frank's moogladder~ v.02 compiled against pd 0.40_2 The code should go in svn somewhere. ( I replaced 2*M_PI in the code with TWO_PI to avoid a multiply (compiler optimisation maybe does that already)). Thanks, Martin! Out of curiosity - what compiler did you use? I've never compiled externals on win xp but would like to learn how. Is it possible to use the free version of MS Developer Studio? Other alternatives? Yes I used the free VisualC++ 2005 Express Edition. I use pd.lib from Miller's pd, to link against when building an external as a dll. The setup function is the only symbol that needs to be exported.. You can also do it using MinGW (pd-extended is built that way) but I haven't yet found the patience to jump through all the hoops to get it working. Cygwin's gcc should work as well for externals. I'd like to try to make a stereo version of moogladder~ and also try tanh optimizations to reduce the cpu load. I'm not sure tanh can be optimized much more. If your CPU has a floating point unit built in, which they all do nowadays, that ought to be the fastest way to calculate it apart from having a huge lookup table. If tanh(x) = (e^x - (1/e^x)) / (e^x + (1/e^x)) the e^x only needs to be calculated once, a = e^x, then b = 1/(e^x), then tanh = (a-b)/(a+b). I would imagine that the FPU already does it that way but I don't know. Probably it could be approximated faster, but isn't the idea to have the most accurate value? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: ( I replaced 2*M_PI in the code with TWO_PI to avoid a multiply (compiler optimisation maybe does that already)). Did you define that yourself? My math.h doesn't have TWO_PI ... Yes. My math.h doesn't seem to have have M_PI either... Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Hi, Yes true. Claude had the reason. I will make a #define as well when I add it to the SVN. Ciao -- Frank On 27.08.2008, at 14:47, Martin Peach [EMAIL PROTECTED] wrote: Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: ( I replaced 2*M_PI in the code with TWO_PI to avoid a multiply (compiler optimisation maybe does that already)). Did you define that yourself? My math.h doesn't have TWO_PI ... Yes. My math.h doesn't seem to have have M_PI either... Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Csound defines M_PI... from the manual: Predefined Math Constant Macros New in Csound 5.04 are predefined Math Constant Macros. The values defined are those found in the C header math.h, and are automatically defined when Csound starts and available for use in orchestras. J On Aug 27, 2008, at 5:47 AM, Martin Peach wrote: Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: ( I replaced 2*M_PI in the code with TWO_PI to avoid a multiply (compiler optimisation maybe does that already)). Did you define that yourself? My math.h doesn't have TWO_PI ... Yes. My math.h doesn't seem to have have M_PI either... Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
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. Ciao -- Frank Barknecht ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Csound opcode Moogladder to Pd?
Frank - that was fast! Thanks! I haven't had time to try it out yet but will report back when I get home. The csound opcode I've used myself is a modification of the original with signal input for cutoff (please find it attached). Signal input for both cutoff and resonance would of course be awesome. If anyone could compile a windows binary of this I would be very grateful. I use both winxp and ubuntu. /Anton ml_aak-csound.csd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
Hi, I once made some kind of implementation of the Moogladder filter to Pd. I never evaluated the implementation so I'm not sure if it really sounds as the Csound version or gives the same output as in the paper. It is kind of crude Pd code anyway. =) But I'll attach the patch here if you wan to give it a try? -Mika Message: 2 Date: Mon, 25 Aug 2008 22:49:11 +0200 From: Anton H?rnquist [EMAIL PROTECTED] Subject: [PD] Csound opcode Moogladder to Pd? To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 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 #N canvas 181 68 924 573 12; #X obj 47 316 phasor~ 100; #X obj 47 406 dac~; #X msg 51 202 \; pd dsp 1; #X msg 144 204 \; pd dsp 0; #N canvas 144 240 793 706 moog 1; #X obj 221 138 filter; #X obj 225 173 filter; #X obj 229 216 filter; #X obj 232 252 filter; #X obj 106 197 *~ 0; #X floatatom 148 177 5 0 0 0 - comp -; #X obj 72 489 *~ 0; #X floatatom 130 466 5 0 0 0 - res -; #X obj 71 522 *~ 4; #X obj 234 103 -~; #X obj 114 65 inlet~; #X obj 20 18 block~ 1 1 1; #X obj 71 559 delwrite~ delay 1; #X obj 74 403 fexpr~ tanh($x1[0]); #X obj 373 381 outlet~; #X obj 74 447 -~; #X obj 530 174 *~ 0; #X obj 481 199 *~ 0; #X obj 425 216 *~ 0; #X obj 382 247 *~ 0; #X obj 344 280 *~ 0; #X obj 593 154 r a; #X obj 579 186 r b; #X obj 557 215 r c; #X obj 518 241 r d; #X obj 495 281 r e; #X msg 46 261 stop; #X msg 16 294 start; #X obj 284 39 delread~ delay 0.002676; #X floatatom 556 328 5 0 0 0 - - -; #X obj 540 623 s g; #X obj 557 410 / 44100; #X obj 556 355 * 6.2832; #X obj 635 379 samplerate~; #X obj 555 385 t f b; #X obj 561 469 pow 2; #X obj 611 466 pow 3; #X obj 664 466 pow 4; #X obj 644 497 * 0.0202; #X obj 486 496 * 0.4342; #X obj 394 496 * 0.9892; #X obj 557 440 t f f f f; #X obj 462 532 -; #X obj 618 527 -; #X obj 538 560 +; #X floatatom 540 594 5 0 0 0 - - -; #X obj 572 497 * 0.1381; #X obj 557 291 r cut; #X connect 0 0 1 0; #X connect 0 0 17 0; #X connect 1 0 2 0; #X connect 1 0 18 0; #X connect 2 0 3 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 3 0 13 0; #X connect 4 0 15 1; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 7 0 6 1; #X connect 8 0 12 0; #X connect 9 0 0 0; #X connect 9 0 16 0; #X connect 10 0 9 0; #X connect 10 0 4 0; #X connect 13 0 15 0; #X connect 15 0 6 0; #X connect 16 0 14 0; #X connect 17 0 14 0; #X connect 18 0 14 0; #X connect 19 0 14 0; #X connect 20 0 14 0; #X connect 21 0 16 1; #X connect 22 0 17 1; #X connect 23 0 18 1; #X connect 24 0 19 1; #X connect 25 0 20 1; #X connect 26 0 13 0; #X connect 27 0 13 0; #X connect 28 0 9 1; #X connect 29 0 32 0; #X connect 31 0 41 0; #X connect 32 0 34 0; #X connect 33 0 31 1; #X connect 34 0 31 0; #X connect 34 1 33 0; #X connect 35 0 39 0; #X connect 36 0 46 0; #X connect 37 0 38 0; #X connect 38 0 43 1; #X connect 39 0 42 1; #X connect 40 0 42 0; #X connect 41 0 40 0; #X connect 41 1 35 0; #X connect 41 2 36 0; #X connect 41 3 37 0; #X connect 42 0 44 0; #X connect 43 0 44 1; #X connect 44 0 45 0; #X connect 45 0 30 0; #X connect 46 0 43 0; #X connect 47 0 29 0; #X restore 45 371 pd moog; #X floatatom 47 292 5 0 0 0 - freq -; #X floatatom 187 11 7 0 0 0 - freq -; #X obj 32 12 hsl 128 15 20 2 1 0 freq empty sawtooth_frequency -2 -8 0 10 -262144 -1 -1 0 1; #X floatatom 186 47 7 0 0 0 - cut -; #X obj 31 48 hsl 128 15 1 14000 1 0 cut sweep filter_cutoff -2 -8 0 10 -262144 -1 -1 0 1; #X obj 32 87 hsl 128 15 0 1 0 0 res empty filter_resonance -2 -8 0 10 -262144 -1 -1 0 1; #X floatatom 188 83 5 0 0 0 - res -; #X obj 33 127 hsl 128 15 0 1 0 0 comp empty filter_comp -2 -8 0 10 -262144 -1 -1 0 1; #X floatatom 192 123 5 0 0 0 - comp -; #X obj 312 16 vsl 15 128 -10 10 0 0 a empty A 0 -9 0 10 -262144 -1 -1 0 1; #X floatatom 304 159 5 0 0 0 - a -; #X obj 366 16 vsl 15 128 -10 10 0 0 b empty B 0 -9 0 10 -262144 -1 -1 0 1; #X floatatom 358 159 5 0 0 0 - b -; #X obj 420 16 vsl 15 128 -10 10 0 0 c empty C 0 -9 0 10 -262144 -1 -1 0 1; #X floatatom 412 159 5 0 0 0 - c -; #X obj 470 13 vsl 15 128 -10 10 0 0 d empty D 0 -9 0 10 -262144 -1 -1 0 1; #X floatatom 462 156 5 0 0 0 - d -; #X obj 521 12 vsl 15 128 -10 10 0 0 e empty E 0 -9 0 10 -262144 -1 -1 0 1; #X floatatom 513 155 5 0 0 0 - e -; #X obj 279 304 noise~; #X obj 205 482 writesf~ 1; #X msg 238 426 start; #X msg 243 453 stop; #X obj 489 322 line; #X msg 537 268 1 4000; #X floatatom 491 358 5 0 0 0 - - sweep; #X msg 440 269 100; #X msg 198 393 open lowpass_500; #X connect 0 0 4 0; #X connect 4 0 1 0; #X connect 4 0 1 1
Re: [PD] Csound opcode Moogladder to Pd?
Hallo, Anton H?rnquist hat gesagt: // Anton H?rnquist wrote: Frank - that was fast! Thanks! I haven't had time to try it out yet but will report back when I get home. The csound opcode I've used myself is a modification of the original with signal input for cutoff (please find it attached). Signal input for both cutoff and resonance would of course be awesome. I now made a version where cutoff and resonance are signals. This version is a bit more CPU intensive now, as some computations had to move into the DSP loop to react to the changes in center frequency. I played a bit with a rational tanh approximation from the music-dsp list but it didn't sound good anymore. If someone wants to play with other approximations e.g. table lookup: Just change the function mytanh. The filter response gets nasty and loud if the center frequency is near or above the sampling rate. Maybe it should be restricted as well. But then, resonance at 1 will make everyone jump, too... The updated code is at http://footils.org/pkg/moogladder-0.2.tgz Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Csound opcode Moogladder to Pd?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
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 ... Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Csound opcode Moogladder to Pd?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
