Re: [PD] moog~ in pure pd?
On 10/11/2013 08:32 AM, Dan Wilcox wrote: [vcf~] sounds close, but of course, it's a band pass so it's not a real replacement. the undocumented 2nd output of vcf~ is a lowpass. and there are a few methods to build the basic (cookbook) filters with pd-vanilla-objects: you could use fexpr~ to make your own signal-rate biquad. it works very well, but needs a lot more cpu than necessary. or you could use cpole~/czero~. like in the beequad-abstractions. i have used the same method in all my filters, with signal-rate. (in my instruments collection on my homepage). of course this is still not exactly moog~. it should be possible though to make a moog-abstraction in the same way, but i have not tried (yet)... maybe anyone else has already? bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pure Data and Korg Monotribe
On 08/27/2013 05:41 AM, Pagano, Patrick wrote: I have a metro on about 200 triggering about 9 bangs for a [random 127] and the values are bopping all over the place and i would like them to move smoothly from random number to random number like a knob would. Can someone help me out with that? Is line what i want? or Vline? 'line' should do the trick: you can for example connect a [pack f 200] to the 'random', and a 'line' to the 'pack'. though maybe it is more interessting to randomize the 'slide time' too... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd version 0.25-0 test 2 released
On 08/19/2013 08:11 AM, Miller Puckette wrote: Hi all - I've now put out test 2 there seems to be a new behaviour concerning tabread4~ and upsampling: (compared to 044, i have not checked the 1st 045 version) in 044 the frequency of the phasor reading the table had to be multiplied by the upsampling factor, to get the right output frequency. in 045 the output frequency of such oscillators much higher. this seems to happen only with tabread(4)~, the example in 'j07 oversampling' works as expected, but many of my bass-synth-patches sound a little squeaky now. ;) i have attached an example with tabread4~. #N canvas 130 266 876 628 10; #X obj 562 67 until; #X obj 562 95 f; #X obj 593 97 + 1; #X obj 557 154 t f f; #X obj 564 13 loadbang; #X obj 594 118 mod 515; #X msg 564 40 515; #X obj 529 633 table \$0triwave 515; #X obj 419 268 mod 512; #X obj 474 545 tabwrite \$0triwave; #X obj 513 354 * 2; #X obj 510 380 - 1; #X obj 433 406 *; #X obj 420 295 t f f; #X obj 431 432 / 512; #X obj 507 331 256; #X obj 455 458 -; #X obj 474 483 * 4; #X obj 473 516 + 3; #X obj 445 222 + 128; #X text 475 16 make tri wave; #X obj 78 462 dac~; #X obj 57 418 *~; #N canvas 316 285 1183 715 triosctest 0; #X obj 31 100 phasor~; #X obj 41 74 inlet~; #X obj 45 434 outlet~; #X text 88 75 freq; #X obj 49 183 tabread4~ \$0triwave; #X obj 50 329 *~ 0.125; #X obj 50 352 rzero~ -1; #X obj 50 375 rzero~ -1; #X obj 50 398 rzero~ -1; #X obj 49 203 *~ 0.2368; #X obj 50 249 *~ 0.06261; #X obj 49 226 rpole~ 0.76319; #X obj 49 272 cpole~ 0.85223 0.20194; #X obj 48 300 cpole~ 0.85223 -0.2019; #X text 150 347 filter from pd doc j07.oversampling (modified for 8 times oversampling); #X obj 50 148 *~ 512; #X obj 166 83 block~ 64 1 8; #X text 95 433 filtered tabread; #X connect 0 0 15 0; #X connect 1 0 0 0; #X connect 4 0 9 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 2 0; #X connect 9 0 11 0; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 12 0 13 0; #X connect 12 1 13 1; #X connect 13 0 5 0; #X connect 15 0 4 0; #X restore 5 261 pd triosctest; #X obj 101 369 hsl 128 15 0 1 0 1 empty empty empty -2 -8 0 10 -262144 -1 -1 1400 1; #X obj -8 155 nbx 5 14 -1e+37 1e+37 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 100 256; #X text 101 348 tabread osc; #X obj -5 209 * 8; #X text 45 180 in 44.1 this ensures the correct frequency with 8 times oversampling. in 045.test2 the frequency is much higher; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 3 0; #X connect 2 0 5 0; #X connect 3 0 19 0; #X connect 3 1 9 1; #X connect 4 0 6 0; #X connect 5 0 1 1; #X connect 6 0 0 0; #X connect 8 0 13 0; #X connect 10 0 11 0; #X connect 11 0 12 1; #X connect 12 0 14 0; #X connect 13 0 12 0; #X connect 13 1 15 0; #X connect 14 0 16 0; #X connect 15 0 10 0; #X connect 15 0 16 1; #X connect 16 0 17 0; #X connect 17 0 18 0; #X connect 18 0 9 0; #X connect 19 0 8 0; #X connect 22 0 21 0; #X connect 22 0 21 1; #X connect 23 0 22 0; #X connect 24 0 22 1; #X connect 25 0 27 0; #X connect 27 0 23 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] more about DS
On 05/28/2013 12:11 PM, Roman Haefeli wrote: Hi all Is it possible to have a scalar with a settable position, but which cannot be moved with mouse interaction? yes, by adding a -x to the drawpolygon in the template. I figured I can use arrays to create grids of immutable scalars, but then I don't know how I can detect which specific element/scalar has been clicked on. unfortunately, with -x the struct does no longer report clicks. so it is good for making a ruler/grid which does not interfere with the data, but not good for making a navigation/whatever. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 2D slider
On 04/17/2013 10:00 PM, Thomas Mayer wrote: is there a 2D slider object, similar to a combination of a hslider and vslider, something like the Kaoss Pad touchscreen? thanks to both of you, but both objects are not quite what I had in mind. [grid] behaves exactly like the kaosspad surface. (or xy in reaktor). the only other object i can imagine would be something which only produces coordinate-values when you drag it around. you can easily build something like that with data structures. (or a little less easily a [grid] with 'steady on click' behaviour.) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Changing the grid size when moving objects with shift+arrows
On 03/29/2013 01:10 PM, matijoncek prdoncek wrote: I was wondering if it's possible to change the the number of pixles by which the objects move when you select them and use shift and the cursor buttons to move them. it is possible using the displace msg and pointer from the struct object, using get to get the new (displaced by 10 pixels) position and adding the additional 2 pixels offset with set, so that the object is moved 12 pixels. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Range Slider Object
On 02/04/2013 12:49 AM, Esteban Viveros wrote: Hello, Have pd-extended .43.4 a equivalent to max/msp rslider object? you can rather easily build something similar in vanilla using datastructures. a quick (maybe a little clumsy) example is attached. it is not exactly the same (extend-mode only), but you can use it to set a range. there are a few other drawbacks though: -you have to deal with individual names for the templates etc. (or make an abstraction and build your own state-saving) -accessing the data is not as easy as with a built-in gui element. bis denn! martin #N struct rangetp float x float y float l float r; #N canvas 618 521 450 300 10; #N canvas 111 213 797 539 rslider 1; #X scalar rangetp 28 25 5 153 \;; #N canvas 323 673 449 300 rangetp 1; #X obj 8 3 struct rangetp float x float y float l float r; #X obj 11 34 filledpolygon 111 444 1 l 0 r 0 r 20 l 20 l 0; #X restore 89 393 pd rangetp; #X obj 217 337 pointer; #X obj 87 366 append rangetp x y l r; #X msg 218 311 traverse pd-rslider \, bang; #X obj 97 314 unpack f f f f; #X msg 97 290 20 20 20 256; #X obj 451 311 metro 20; #X obj 451 368 pointer; #X msg 451 346 traverse pd-rslider \, next; #X floatatom 496 452 5 0 0 0 - - -; #X floatatom 552 445 5 0 0 0 - - -; #X obj 452 291 loadbang; #X obj 168 256 t b b; #X obj 168 234 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 498 423 change; #X obj 550 422 change; #X obj 451 393 get rangetp x y l r; #X text 185 18 - why are (sometimes?) only the top corners dragable!? ; #X text 449 262 get the values \, maybe there is a more elegant way using some kind of click-event whatever...; #X text 164 205 create the range slider (needed only once \, or after deleting the slider); #X connect 2 0 3 4; #X connect 4 0 2 0; #X connect 5 0 3 0; #X connect 5 1 3 1; #X connect 5 2 3 2; #X connect 5 3 3 3; #X connect 6 0 5 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 8 0; #X connect 12 0 7 0; #X connect 13 0 6 0; #X connect 13 1 4 0; #X connect 14 0 13 0; #X connect 15 0 10 0; #X connect 16 0 11 0; #X connect 17 2 15 0; #X connect 17 3 16 0; #X restore 48 52 pd rslider; #X text 37 31 horizontal rangeslider using datastructures inside; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing pd silence
On 10/23/2011 08:20 PM, Mathieu Bouchard wrote: How much is a lot ? What's the amplitude in the noise ? If it's something like 1/65536 of the maximum level, that's not what I'd call « a lot »... it is more. after normalizing i had about 8 different sample values (including zero) in the file. the (unnormalized) noise is audible, when the volume is rather high, it is at least 2 times louder than the natural noisefloor of my soundcard/amp/speakers. ...and i have archived all my music as flac using audacity, since 2006. fortunately i should still have the original 32bit float files somwhere in my cdr-pile... it is also explained here: http://wiki.audacityteam.org/wiki/Dither Personally, I don't understand what's the point of dither in audio. Maybe it's just an evil plot to make CD quality sound like 8-track cartridges. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing pd silence
On 10/22/2011 02:39 PM, saskia diez wrote: I just discover this since i bought a nice speakers, before i havent realize that sound editors add that hiss. i could hardly believe that, but you are right! i have just created a file with writesf~, ensured that it contained only zeros (hexeditor), loaded it in audacity, exported as 16bit wav, and after normalizing, there was a lot of noise. Why is that? is it possible to avoid that? dithering maybe? i have checked with another editor (mhwaveedit), and it did not add noise. so using another editor would be a solution. or saving in another format than 16bit wav (other uncompressed format in audacity), you would need another program to convert the file for buring on cd (or whatever) though. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing pd silence
On 10/22/2011 03:49 PM, Pierre-Olivier Boulant wrote: I think you are talking about this: http://en.wikipedia.org/wiki/Dither http://en.wikipedia.org/wiki/Noise_shaping yes, and it is possible to disable this in audacity (edit/preferences/quality setting dither to none) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
On 10/19/2011 07:56 AM, Mathieu Bouchard wrote: Something like ((y^128)-128)/128. and some output filtering to eliminate frequencies above 1/2 of 8 khz. i have just added a few lop~, and i think it sounds quite close now. bis denn! martin #N canvas 101 287 793 443 10; #X obj -61 410 dac~; #X obj -58 113 rpole~ 1; #X msg -95 56 set 0; #X obj -59 85 sig~ 0.181405; #X obj -58 141 expr~ int($v1); #X text 44 146 counter 2 int; #X text -49 55 reset counter; #X text -3 114 counter; #X text 34 87 increment for about 8 khz rate; #X text -159 3 pd implementation of viznuts and bemmus 'one line of code symphonies' presentetd on countercomplex.blogspot.com.; #X obj -55 382 *~ 0.5; #X obj -55 339 lop~ 4000; #X obj -54 361 lop~ 4000; #X obj -55 316 lop~ 4000; #X text 10 343 filter frequencies above 4 khz; #X text -138 185 code here -; #X text 158 281 putchar \, conversion 2 unsigend char; #X text 258 26 some nice formulas:; #X text 255 48 expr~ $v16$v1($v1*$v114)+4095$v1; #X text 254 64 expr~ $v1($v14)3$v17; #X text 255 81 expr~ $v1($v17)|($v14); #X text 255 99 expr~ $v1696969*(sin($v110)); #X text 256 118 expr~ $v1(cos($v1($v17)))|($v18)|($v151|$v132) ; #X text 256 136 expr~ $v14|$v234(($v1*1.5)($v17)); #X obj -56 282 expr~ ((($v10xff)^0x80)-128)/128; #X text 259 10 expr~ $v1*(($v112|$v18)63$v14); #X text 494 9 default; #X obj -59 185 expr~ $v14|$v234(($v1*1.5)($v17)); #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 1 0; #X connect 4 0 27 0; #X connect 10 0 0 0; #X connect 10 0 0 1; #X connect 11 0 12 0; #X connect 12 0 10 0; #X connect 13 0 11 0; #X connect 24 0 13 0; #X connect 27 0 24 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
On 10/18/2011 03:36 AM, hardoff goes bananas wrote: the main dilemma here is that the patch runs at normal samplerate and bitrate. lower samplerates are possible with smaller numbers as input for the counter, and rounding to int i think to get the sound close to the original code examples, you're going to have to somehow force the calculations all to be done with 8bit floats, rather than pd's internal 32 bit (or whatever) I still can't get my head around how to do that. i got it a little closer to the original after applying 0xff like in the javascript on the site, and dividing by 256 (instead of scaling by 256 to fit into short), maybe there is still a lsb/msb issue though. bis denn! martin #N canvas 206 341 444 273 10; #X obj -64 239 dac~; #X obj -62 92 rpole~ 1; #X msg 29 65 set 0; #X obj -60 207 hip~ 10; #X obj -59 179 expr~ ($v1*(($v112|$v18)63$v14) 0xff) / 256 ; #X obj -60 145 -~; #X obj -37 120 wrap~; #X obj -63 64 sig~ 0.181405; #X text -83 -13 pd implementation of the method presented by 'viznut' on the countercomplex-blog. now with (proper?) 'typeconversion' and scaling and about 8 khz samplingrate; #X connect 1 0 6 0; #X connect 1 0 5 0; #X connect 2 0 1 0; #X connect 3 0 0 0; #X connect 3 0 0 1; #X connect 4 0 3 0; #X connect 5 0 4 0; #X connect 6 0 5 1; #X connect 7 0 1 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
On 10/16/2011 02:31 PM, hardoff goes bananas wrote: further condensing of martin's patch: that is probably the most compact version (of course only if expr counts as one object...) it sounds a little different from the message based version though, but this is probably only a matter of tweaking the samplerate. and it repeats after 100(?) seconds, while the first version should run for about a day. i have not tried to make the phasor much slower yet. and my version sounds still different from the c/js version, though quite similar. i think this might be caused by the type conversion to char. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
after i had fun making very small patches which make nice noise, i got the feeling that i was slightly missing the point: On 10/07/2011 02:25 PM, Chris McCormick wrote: http://countercomplex.blogspot.com/2011/10/algorithmic-symphonies-from-one-line-of.html when i had actually read this. implementing it in pd was not as easy as i thought, but i think i have managed, at least it sounds more or less like the examples on the web. i could not get bang~ to bang faster than every 64 samples, regardless of the subpatch blocksize. (or metro below 1 ms) is this really not possible, or did i miss something obvious? bis denn! martin #N canvas 24 185 1029 707 10; #X obj 576 624 dac~; #X obj 580 596 hip~ 10; #X obj 276 126 nbx 5 14 1 64 0 1 empty empty samplerate_divide 0 -8 0 10 -262144 -1 -1 8 256; #X obj 208 222 int; #X obj 243 249 + 1; #X msg 91 74 0; #X obj 270 -55 bang~; #X obj 270 -1 until; #X msg 270 -31 64; #X obj 264 28 f; #X obj 295 30 + 1; #X obj 339 30 sel 0; #X obj 295 55 mod 64; #X obj 516 542 table \$0blockbuffer 64; #X obj 512 518 tabwrite \$0blockbuffer; #X text 121 76 restart from 0; #X text 238 222 count to 'infinity'; #X obj 294 80 t f f; #X obj 199 565 clip -1 1; #X obj 579 565 tabreceive~ \$0blockbuffer; #X obj 310 -54 block~ 64; #X text 303 -30 count to blocksize; #X text 10 462 code here -; #X obj 227 145 mod 8; #X obj 465 496 float; #X obj 490 452 t b f; #X obj 227 169 sel 0; #X obj 272 334 nbx 5 14 0 128 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 12 256; #X obj 303 362 nbx 5 14 0 128 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 8 256; #X obj 354 388 nbx 5 14 0 128 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 63 256; #X obj 113 463 expr $f1 * (($f1$f2|$f1$f3)$f4$f1$f5); #X obj 399 418 nbx 5 14 0 128 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 4 256; #X text 321 317 parameters; #X text -108 -47 pd implementation of the method presented by 'viznut' on the countercomplex-blog.; #X text 423 -38 since i was not able to get messages faster than 64 samples (metro not faster than 1 ms (and bang~ too)) \, i had to calculate a buffer on blockstart.; #X obj 479 302 unpack f f f f; #X msg 498 214 12 8 63 4; #X msg 544 240 13 8 55 3; #X text 569 210 standard; #X msg 604 270 17 11 91 2; #X connect 1 0 0 0; #X connect 1 0 0 1; #X connect 2 0 23 1; #X connect 3 0 4 0; #X connect 3 0 30 0; #X connect 4 0 3 1; #X connect 5 0 3 1; #X connect 6 0 8 0; #X connect 7 0 9 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 10 0 12 0; #X connect 11 0 7 1; #X connect 12 0 9 1; #X connect 12 0 11 0; #X connect 12 0 17 0; #X connect 17 0 23 0; #X connect 17 1 25 0; #X connect 18 0 24 0; #X connect 19 0 1 0; #X connect 23 0 26 0; #X connect 24 0 14 0; #X connect 25 0 24 0; #X connect 25 1 14 1; #X connect 26 0 3 0; #X connect 27 0 30 1; #X connect 28 0 30 2; #X connect 29 0 30 3; #X connect 30 0 18 0; #X connect 31 0 30 4; #X connect 35 0 27 0; #X connect 35 1 28 0; #X connect 35 2 29 0; #X connect 35 3 31 0; #X connect 36 0 35 0; #X connect 37 0 35 0; #X connect 39 0 35 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
improved version of my 1st one (got rid of the lame random), another feedback-based, and a fm-tuningfork with echo. bis denn! martin #N canvas 586 335 387 350 10; #X obj 160 252 dac~; #N canvas 826 407 450 300 stuff 1; #X obj 48 227 cos~; #X obj 90 133 *~; #X obj 52 53 phasor~ 1; #X obj 131 23 +~ 1; #X obj 4 138 *~ 0.36; #X obj 90 159 vd~ \$0delay; #X obj 48 93 delwrite~ \$0delay 100; #X obj 227 156 threshold~ 0.1 100 0 100; #X obj 92 267 outlet~; #X obj 166 269 outlet~; #X obj 361 3 block~ 1; #X obj 283 68 snapshot~; #X obj 294 133 clip 0 69; #X obj 286 89 abs; #X obj 290 111 * 69; #X connect 0 0 4 0; #X connect 0 0 7 0; #X connect 1 0 5 0; #X connect 2 0 1 0; #X connect 2 0 6 0; #X connect 3 0 1 1; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 4 0 8 0; #X connect 5 0 0 0; #X connect 5 0 4 0; #X connect 5 0 9 0; #X connect 5 0 11 0; #X connect 7 0 11 0; #X connect 11 0 13 0; #X connect 12 0 3 0; #X connect 13 0 14 0; #X connect 14 0 12 0; #X restore 157 183 pd stuff; #X connect 1 0 0 0; #X connect 1 1 0 1; #N canvas 174 392 450 300 10; #X obj 54 230 dac~; #N canvas 299 491 450 300 stuff 1; #X obj 55 148 samphold~; #X obj 110 187 *~; #X obj 123 253 vd~ \$0delay; #X obj 288 79 block~ 1; #X obj 124 280 outlet~; #X obj 149 150 osc~; #X obj 54 40 phasor~ 1.11803; #X obj 162 48 phasor~ 1.41421; #X obj 149 130 +~ 220; #X obj 149 108 *~ 440; #X obj 87 219 *~ 99; #X obj 202 221 delwrite~ \$0delay 100; #X obj 191 190 *~ 0.99; #X connect 0 0 1 0; #X connect 0 0 10 0; #X connect 1 0 11 0; #X connect 2 0 4 0; #X connect 2 0 12 0; #X connect 5 0 1 1; #X connect 6 0 0 0; #X connect 6 0 9 0; #X connect 6 0 0 1; #X connect 7 0 0 1; #X connect 7 0 9 0; #X connect 8 0 5 0; #X connect 9 0 8 0; #X connect 10 0 2 0; #X connect 12 0 11 0; #X restore 54 180 pd stuff; #X connect 1 0 0 0; #X connect 1 0 0 1; #N canvas 546 306 419 359 10; #X obj 115 309 dac~; #X obj 127 199 osc~; #X obj 129 176 *~; #X obj 111 20 phasor~ -1; #X obj 208 85 samphold~; #X obj 158 148 *~; #X obj 196 252 delread~ \$0delay 750; #X obj 80 88 *~; #X obj 218 172 *~ 0.95; #X obj 138 228 *~ 0.4; #X obj 182 123 *~ 500; #X obj 345 38 adc~; #X obj 123 114 osc~ 440; #X obj 245 222 delwrite~ \$0delay 1000; #X connect 1 0 0 0; #X connect 1 0 9 0; #X connect 2 0 1 0; #X connect 3 0 4 1; #X connect 3 0 7 1; #X connect 3 0 7 0; #X connect 4 0 10 0; #X connect 5 0 2 1; #X connect 6 0 0 0; #X connect 6 0 4 0; #X connect 6 0 8 0; #X connect 7 0 2 0; #X connect 8 0 0 1; #X connect 8 0 13 0; #X connect 9 0 0 1; #X connect 9 0 13 0; #X connect 10 0 5 1; #X connect 11 0 4 1; #X connect 11 0 13 0; #X connect 11 1 4 1; #X connect 11 1 13 0; #X connect 12 0 5 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
these minimal patches are fun! the idea reminds me a little of the sc140 project: http://supercollider.sourceforge.net/sc140/ here is my 1st one. bis denn! martin #N canvas 424 308 387 350 10; #X obj 125 242 dac~; #X obj 48 227 cos~; #X obj 90 133 *~; #X obj 52 53 phasor~ 1; #X obj 131 23 +~ 1; #X obj 4 138 *~ 0.36; #X obj 164 -5 random 69; #X obj 91 165 vd~ \$0delay; #X obj 48 93 delwrite~ \$0delay 100; #X obj 227 156 threshold~ 0.1 100 0 100; #X connect 1 0 5 0; #X connect 1 0 9 0; #X connect 2 0 7 0; #X connect 3 0 2 0; #X connect 3 0 8 0; #X connect 4 0 2 1; #X connect 4 0 3 0; #X connect 5 0 0 0; #X connect 5 0 8 0; #X connect 6 0 4 0; #X connect 7 0 0 1; #X connect 7 0 1 0; #X connect 7 0 5 0; #X connect 9 0 6 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] very compressed chip sounds
and another one, bis denn! martin #N canvas 559 407 450 300 10; #X obj 83 251 dac~; #X obj 76 203 osc~; #X obj 141 68 wrap~; #X obj 121 127 vd~ \$0delay; #X obj 131 234 delwrite~ \$0delay 1000; #X obj 75 181 mtof~; #X obj 68 33 phasor~ 0.707106; #X obj 259 31 phasor~ 0.866025; #X obj 75 158 *~ 35; #X obj 143 103 *~ 550; #X connect 1 0 0 0; #X connect 1 0 4 0; #X connect 2 0 8 0; #X connect 2 0 9 0; #X connect 3 0 8 0; #X connect 3 0 0 1; #X connect 5 0 1 0; #X connect 6 0 2 0; #X connect 6 0 8 0; #X connect 7 0 2 0; #X connect 7 0 4 0; #X connect 7 0 9 0; #X connect 8 0 5 0; #X connect 9 0 3 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Appending two signals together to create a third
On 09/01/2011 11:51 AM, Rick T wrote: For more background I'm going to have the Frequency, Amplitude, and Phase controlled by Midi Controllers. So there will be a total of 9 midi controllers used (3 for each signal). i think independent control of the 3 frequencies makes this a little tricky. appending the waveform exactly at cycle-boundaries will only happen at certain frequency ratios. the best i could come up with so far was a frequency ratio and another control for the splitpoint (attached). for 1:1 or 2:1 etc. you get more or less exactly appended waves. (and changing a frequency-ratio makes quite nice sweep- or sync like sounds) i have not tried yet, but maybe it is also possible to compute the waveform with the desired nrs of b and c cycles with messages, scale the resulting table to the size of one block, and reblock the patch to fit the frequency of d. this would always guarantee exactly appended waves, though not with precise control over the frequencies of b and c. bis denn! martin #N canvas 317 118 998 883 10; #X obj 190 -35 phasor~; #X obj 46 177 wrap~; #X obj 45 198 *~ 512; #X obj 159 193 *~ 512; #X obj 159 172 wrap~; #X obj 103 598 dac~; #X obj 127 435 +~; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0display 512 float 0; #X coords 0 1.5 511 -1.5 256 140 1 0 0; #X restore 285 542 graph; #X obj 287 504 tabwrite~ \$0display; #X msg 347 467 bang; #X obj 190 -63 nbx 5 14 0 1 0 1 empty empty freq_D 0 -8 0 10 -262144 -1 -1 145 256; #X obj 64 372 *~; #X obj 100 317 nbx 5 14 0 100 0 1 empty empty amp1 0 -8 0 10 -262144 -1 -1 100 256; #X obj 96 339 / 100; #X obj 222 377 *~; #X obj 258 322 nbx 5 14 0 100 0 1 empty empty amp2 0 -8 0 10 -262144 -1 -1 100 256; #X obj 254 344 / 100; #X obj 22 82 nbx 5 14 0 100 0 1 empty empty phase1 0 -8 0 10 -262144 -1 -1 1 256; #X obj 27 108 / 100; #X obj 55 155 +~; #X obj 179 106 nbx 5 14 0 100 0 1 empty empty phase2 0 -8 0 10 -262144 -1 -1 0 256; #X obj 176 124 / 100; #X obj 159 150 +~; #X obj 107 538 *~ 0.5; #X text 3 172 osc B; #X text 199 172 osc C; #X obj 522 313 table \$0waveB 515; #X obj 522 335 table \$0waveC 515; #X obj 158 217 tabread4~ \$0waveC; #X obj 39 222 tabread4~ \$0waveB; #X text 390 463 click to display wave; #X obj 593 -46 until; #X obj 593 -18 f; #X obj 624 -16 + 1; #X obj 633 153 sin; #X obj 632 130 * 6.28319; #X obj 588 41 t f f; #X obj 595 -100 loadbang; #X obj 517 142 mod 2; #X obj 527 166 * 2; #X obj 528 191 - 1; #X obj 632 104 / 512; #X obj 513 118 div 256; #X obj 625 5 mod 515; #X msg 595 -73 515; #X obj 515 228 * -1; #X obj 657 178 tabwrite \$0waveB; #X obj 509 261 tabwrite \$0waveC; #X obj 62 294 *~; #X obj 200 313 *~; #X obj 94 94 *~; #X obj 130 93 *~; #X obj 156 56 * 2; #X obj 194 56 * 2; #X obj 266 -62 nbx 3 14 1 99 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 2 256; #X obj 314 -62 nbx 3 14 1 99 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 1 256; #X text 302 -64 :; #X text 564 -123 make sine and square waves; #X text 262 -84 waveform frequency ratio; #X obj 396 51 nbx 5 14 -100 100 0 1 empty empty splitpoint 0 -8 0 10 -262144 -1 -1 0 256; #X obj 396 71 / 100; #X obj 302 113 cos~; #X obj 286 215 clip~ 0 1; #X obj 363 205 clip~ -1 0; #X obj 363 225 *~ -1; #X obj 303 142 +~; #X obj 301 62 +~ 0.75; #X obj 301 88 clip~ 1 1.75; #X obj 302 166 *~ 64; #X text 341 126 soft xfade; #X text 464 34 0-1:1; #X connect 0 0 50 0; #X connect 0 0 51 0; #X connect 0 0 66 0; #X connect 1 0 2 0; #X connect 2 0 29 0; #X connect 3 0 28 0; #X connect 4 0 3 0; #X connect 6 0 23 0; #X connect 6 0 8 0; #X connect 9 0 8 0; #X connect 10 0 0 0; #X connect 11 0 6 0; #X connect 12 0 13 0; #X connect 13 0 11 1; #X connect 14 0 6 1; #X connect 15 0 16 0; #X connect 16 0 14 1; #X connect 17 0 18 0; #X connect 18 0 19 1; #X connect 19 0 1 0; #X connect 20 0 21 0; #X connect 21 0 22 1; #X connect 22 0 4 0; #X connect 23 0 5 0; #X connect 23 0 5 1; #X connect 28 0 49 0; #X connect 29 0 48 0; #X connect 31 0 32 0; #X connect 32 0 33 0; #X connect 32 0 36 0; #X connect 33 0 43 0; #X connect 34 0 46 0; #X connect 35 0 34 0; #X connect 36 0 41 0; #X connect 36 0 42 0; #X connect 36 1 46 1; #X connect 36 1 47 1; #X connect 37 0 44 0; #X connect 38 0 39 0; #X connect 39 0 40 0; #X connect 40 0 45 0; #X connect 41 0 35 0; #X connect 42 0 38 0; #X connect 43 0 32 1; #X connect 44 0 31 0; #X connect 45 0 47 0; #X connect 48 0 11 0; #X connect 49 0 14 0; #X connect 50 0 19 0; #X connect 51 0 22 0; #X connect 52 0 50 1; #X connect 53 0 51 1; #X connect 54 0 52 0; #X connect 55 0 53 0; #X connect 59 0 60 0; #X connect 60 0 65 1; #X connect 61 0 65 0; #X connect 62 0 48 1; #X connect 63 0 64 0; #X connect 64 0 49 1; #X connect 65 0 68 0; #X connect 66 0 67 0; #X connect 67 0 61 0; #X connect 68 0 62 0; #X connect 68 0 63 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Appending two signals together to create a third
On 09/04/2011 01:46 PM, martin brinkmann wrote: and reblock the patch to fit the frequency of d. this would always guarantee exactly appended waves, though not with precise control over the frequencies of b and c. ...and of course somehow write the result to normal (power of 2) sized blocks for audio output, bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] making puredata headphone-safe
On 08/23/2011 11:47 PM, Richie Cyngler wrote: (whatever kind of sound gen you like) | [*~ 0.2] | \ [dac~] i think you should put a clip -1 1 before the *~ 0.2. otherwise, if you connect something like osc~ *~ 1 for example, you would get some very loud drilling sound at the dac~ ,which should(!?) also clip at -1 1, but this might be too loud already... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd performance at TED
On 06/21/2011 08:05 AM, Ingo wrote: All lines are played live. There is no pre-recorded drum loop. He is using audio looping only. The drums are played note by note. ... you are right, and after having watched the video another time, i agree to your observations. (and meanwhile it has been 'officially confirmed' anyway) Well, I really don't know why there is a reason fort he audience to know what is going on. at least i want to know, and i think i am not alone... Does the audience have to know how a piano was built in order to appreciate and enjoy piano music? no, but people know what a piano or a violin is, and at least have a rough idea of how it is played, so that 'understanding what is going on' is usuallay not an issue. this is different with electronic music. i think this article by robert henke www.monolake.de/interviews/supercomputing.html explains the problems we have with life performance/electronic music quite well. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd performance at TED
On 06/20/2011 01:43 PM, Marco Donnarumma wrote: Ingo, thanks for your explanation, I think to understand how he's playing. i do not think i do (completely), though i have only watched it twice so far. it seems that everything is based heavily on live-looping. at first i thought he was using some kind of midi/parameter-looping, like recording the chords first, and the filter/fx/whatever parameters in a second pass, but after watching it the second time, i noticed, that the chords (including sound parameters) repeat exactly while he was doing something else, like it would be the case with audio-looping. i can not tell if the chords/melodie are presets triggered with the buttons (thats probably what i would do) or played in a completely open way, maybe using a preset scale or something similar. and i wonder how he managed to sync the drumloop (if it is one, and not something recorded using the buttons/wind controller) to the chord loops recorded earlier. (in-ear) monitor and some kind of metro/click track would of course explain this. i think this uncertainty of what is going on 'on stage' is a general problem with electronic music, which was (obviously) not solved with this performance either, since even people who know about this stuff have only vague ideas of what is happening. for an audience with a background in electronic/computer/whatever music, a authentic and satisfying performance might be less challenging though. an obvious example is live coding, where it is totally clear to the audience what is happening. but even a 'laptop gig' becomes less boring, when you can see what is happening on the screen (of course only if there is something happening), for example in a mirror behind the performer. (works very well in very small venues as far as i have experienced) This might be a very personal take, but if movement is secondary in gestural control, why one uses gestural control at all? it is probably not secondary all the time, but only when he is doing something else (with the wind controller for example), and the previously recorded loop plays on. and even if it is only 'secondary', movement/dancing is certainly very helpful to stay in sync. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] euclidean rhythms
On 05/26/2011 01:29 AM, Martin Dupras wrote: In other words: let's say you want 5 beats in a grid of 12 (or a 12-sided polygon, if we use his graphical representation), the exact spacing between two beats would be 12/5, or 2.4. The first beat would be 0*2.4= 0. The second beat would 1*2.4 = 2.4, rounded to 2 The third would be 2*2.4 = 4.8, which we round to 5. The fourth would be 3*2.4= 7.2, which we round to 7. The fifth would be 4*2.4 = 9.6, which we round to 10. We now have the pattern x.x..x.x..x. though the flash app (at hisschemoeller.com) produces soemthing like x..x..x.x.x. the number and length of rests is the same in this case, but the distribution is different. if you, instead of rounding, just cut the fractional part, you get the same result as the flash app, only mirrored, but this seems not to work for other numbers. i have attached my own quick and dirty itterative attempt, but i think it should also be possible to implement with operations on lists, like in the ruinwesen example. but i am not that familliar with this in pd... bis denn! martin #N canvas 98 91 985 910 10; #X obj 326 59 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 231 35 steps; #X text 168 35 len; #X obj 223 125 -; #X obj 254 86 t b f; #X floatatom 204 178 5 0 0 0 - - -; #X obj 228 363 mod; #X obj 265 231 until; #X obj 265 259 f; #X obj 296 261 + 1; #X obj 340 261 sel 0; #X obj 296 282 mod 64; #X obj 264 201 int; #X obj 325 408 tabread \$0rests; #X obj 329 85 t b b; #X text 323 39 clear and recalculate; #X obj 322 434 + 1; #X obj 238 488 tabwrite \$0rests; #X obj 241 386 t b f f; #X obj 241 464 int; #X obj 445 165 until; #X obj 445 193 f; #X obj 476 195 + 1; #X obj 520 195 sel 0; #X obj 476 216 mod 64; #X msg 445 142 64; #X obj 467 293 tabwrite \$0rests; #X obj 477 251 t b f; #X msg 468 271 0; #X text 503 162 clear; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0rests 64 float 2; #X coords 0 16 64 0 256 128 1 0 0; #X restore 365 480 graph; #X text 137 159 nr of rests; #X text 308 620 ...and now do something with the rythmn-data in the table...; #X obj 167 700 mod; #X obj 48 623 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 166 55 nbx 5 14 1 64 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 12 256; #X obj 237 57 nbx 5 14 1 64 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 5 256; #X msg 333 231 0; #X text 291 202 for nr of rests do; #X text 282 348 put nr of 'silent steps' following each 'active' step into a table; #X obj 122 655 f; #X obj 156 662 + 1; #X obj 188 799 delay; #X obj 167 724 tabread \$0rests; #X obj 228 776 *; #X obj 191 749 t b f; #X obj 299 708 nbx 5 14 10 2000 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 277 256; #X text 298 692 steplen in ms; #X text 78 697 sequencer; #X text 461 664 ping; #X obj 510 747 line~; #X msg 513 711 0 100; #X msg 563 708 1; #X obj 445 809 *~; #X obj 428 734 osc~ 440; #X obj 511 672 t b b; #X obj 506 783 *~; #X obj 438 863 dac~; #X obj 442 836 *~ 0.5; #X text 23 602 start playing; #X connect 0 0 14 0; #X connect 3 0 5 0; #X connect 3 0 12 1; #X connect 4 0 3 0; #X connect 4 1 3 1; #X connect 6 0 18 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 8 0 6 0; #X connect 9 0 11 0; #X connect 10 0 7 1; #X connect 11 0 10 0; #X connect 11 0 8 1; #X connect 12 0 7 0; #X connect 13 0 16 0; #X connect 14 0 12 0; #X connect 14 1 25 0; #X connect 14 1 37 0; #X connect 16 0 19 1; #X connect 18 0 19 0; #X connect 18 1 17 1; #X connect 18 2 13 0; #X connect 19 0 17 0; #X connect 20 0 21 0; #X connect 21 0 22 0; #X connect 22 0 24 0; #X connect 23 0 20 1; #X connect 24 0 23 0; #X connect 24 0 21 1; #X connect 24 0 27 0; #X connect 25 0 20 0; #X connect 27 0 28 0; #X connect 27 1 26 1; #X connect 28 0 26 0; #X connect 33 0 43 0; #X connect 34 0 40 0; #X connect 35 0 3 0; #X connect 35 0 33 1; #X connect 36 0 4 0; #X connect 36 0 6 1; #X connect 37 0 8 1; #X connect 40 0 41 0; #X connect 40 0 33 0; #X connect 41 0 40 1; #X connect 42 0 34 0; #X connect 42 0 55 0; #X connect 43 0 45 0; #X connect 44 0 42 1; #X connect 45 0 42 0; #X connect 45 1 44 0; #X connect 46 0 44 1; #X connect 50 0 56 0; #X connect 50 0 56 1; #X connect 51 0 50 0; #X connect 52 0 50 0; #X connect 53 0 58 0; #X connect 54 0 53 0; #X connect 55 0 51 0; #X connect 55 1 52 0; #X connect 56 0 53 1; #X connect 58 0 57 0; #X connect 58 0 57 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Midi note handling for monophonic synth
On 04/21/2011 01:48 PM, Joe White wrote: http://kemptonmooney.com/2010/09/pure-data-midi-note-off-solution/ this does not happen here, using the method from the monosynth example in the pd-help. (stripnote), 3. c10. however the sound stops, if the last pressed key is released. if this is not desired, maybe a counter for note on/off msg (and stopping the sound at 0) would help, so that the sound is only stopped when all keys are released. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI triggered samples
On 03/25/2011 09:44 PM, Xavier Miller wrote: Wouldn't be possible to mix the best of both worlds (tabread4~ and sfread~) by pre-loading the first (milli-)seconds of each sound in memory, then switch to streaming i remember a couple of years ago something like this was posted to the list. unfortunately i cannot find it in the archive, but basicly the idea was: load a second of audio into a table, start playback of the table and open the rest of the soundfile with readsf, and start readsf-playback with 1 second delay (and switch from tableplayback to diskstream, also with 1 sec. delay). as far as i remember, this worked very well. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music Made with Pd
On 02/09/2011 01:02 PM, Pedro Oliveira wrote: But about the technical setup it was my first time ever performing live with Pd, so I kind of created an ensemble of possibilities I could work with, however limiting myself to only four channels... i think it depends on what is going on in a 'channel', whether 4 is a limit, or the maximum number of things one can handle as a solo performer. if it is basically a volume level, even much larger numbers should be possible, while a single complex granular synthesizer might be enough for a single player. One of the channels deal with, yes, granular synthesis (thanks to the nqpolywrap object) using long samples from the recordings (from 20 to 60 seconds), but what makes them interesting is the range that I allow the grains to be selected from. i have never heard of this object (i use pd vanilla, with only a few externals most of the time, so it is probably included in extended?) how are the grains selected? in my granular patches i have only used position+random jitter so far, but more complex patterns, or a mixture of grains from different positions might be interesting too. maybe a good idea for a new granular patch... The second channel has another really simple synth based on two phasors, plus buckets full of reverb and some samphold to add dirt. that was probably what i thought was the 'resampling effect'. (not completely wrong though ;)) The third channel is a so-called bass where I generate a random table with six values, and play them with the Monome so everytime I generate new values for the table I get new notes I'm not aware of, therefore I have to think really quick. did you generate the values 'manually' on demand, or by some kind of automatism (a metro for example)? i think both could be quite challenging, while the latter variant provides less control for the human performer... Yeah, that's it. I tried to keep it really simple to avoid overwhelming my processor and to be able to control as many parameters I could with the devices. I don't know if it was clever, but it was my own way of solving it... large sets of parameters are always a problem, and some kind of automation might be necessary to deal with the complexity. i think the concept of 'scenes' can help a lot, like switching (or crossfading) different pre-programmed sets of parameters. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music Made with Pd
On 02/07/2011 11:21 PM, Pedro Oliveira wrote: Last weekend I did a small performance at the Hochschultage at the HfK Bremen, Germany. This is from a project called Performance for One which is a small part of my research - more info about that soon ;) unfortunately i missed your performance when i was at the hfk last weekend. i listened to your 'sound of nowhere' excerpt at the 'sound culture lounge' though. the surrounding was a bit noisy for most of the rather quiet ambient pieces, but i enjoyed it nevertheless. 100% improvised and played on the fly with a monome and a korg nanokontrol, no edits... and the samples come from my own recordings from rehearsals for Mozart's Don Giovanni at the Theater Bremen in 2010. since im am always interested in live performance of 'computer music', (all my own music is recorded live with pd+controller in a kind of dub-like way) i would of course like to know what you were doing there. some kind of slowed down samples (granular? phase vocoder?) and kind of resampling (maybe scanned synthesis?) i guess from the recording, but i would really like to know the details. http://soundcloud.com/iburiedpaul/live-at-hfk-bremen bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The Game of Life
On 11/29/2010 11:09 AM, Andrew Faraday wrote: How did you use the data from your grid to generate the music? my grid is a (virtual)tenori-on-ish sequencer, and: Was it the straight-forward each position represents a note approach, exactly. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The Game of Life
On 11/28/2010 09:21 PM, Andrew Faraday wrote: also, I can't get this to work on my mac, not entirely sure why, oh well. never mind. works here on macos in pd extended 0.42.5. the cpu load is a bit heavy though, on my 2009 mac mini. (about 70 percent) i also got a few r13 couldn't create. on my ubuntu (10.4) it did not work very well, but that is probably because i use basicly pd vanilla and a few externals (and no gridflow for example). after randomize the next iteration is completely black. cpu is about 50 percent (3 ghz intel core duo) Does anyone know if it's been done in puredata before? Can I get hold of it? I may, in the longer run, be planning to use this for a generative music patch. Don't know if that means anything to you. in my sequenzquadrat-patch is a live-player, which modifies the current pattern according to game-of-life rules. musically it is not that interessting though. maybe it would be a better idea to use the game-of-life in a different way than i did, for example as a monophonic sequence, with nr of dots per column as velocity or something like that. or maybe clusters of dots as different sequences... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] simple complex FM-Synthesis with pure Data
On 08/17/2010 09:52 AM, hghoyer wrote: I have the FM patch improved a little. With the link it can be downloaded. I welcome feedback on the patch. Maybe someone else has a suggestion for improvement. i think i would add a slider (or better number2) for the frequency ratios, which are fixed values in your patch. these have great influence on the sound. dynamicly changing the modulation depth of operators (with envelopes, lfos, sequencers,---) could create interessting sounds too. using set-messages and loadbang for remembering the slider-values is not necessary: you could just set init in the sliders properties. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] I wanna sing like Paris
On 08/16/2010 06:21 PM, Pierre Massat wrote: Hi, I've been thinking of writing a pd version of autotune, but before i get started i m wondering if anybody as ever tried doing this? not in pd, but in reaktor and c. combining pitch-detection and a pitchshifter (and some quantization) works quite well, and should be not too hard to do in pd (fiddle and the pitchshifter from the docs). though this is quite good for subtle pitch correction, it does not create the typical, metallic, vocoder-like cher-effect. maybe something like taking single-cycle-samples of the input, when a constant pitch is detected, and playing these instead of the original audio would do better, but i have not tried yet. (and i think detecting zero-crossings in pd (vanilla) is rather difficult...) I m assuming they're making a ton of money selling it, so there 's probably not much information available as to how it actually works, but i guess Miller Puckette's Phase vocoder example could be a good starting point. i do not think that autotune uses fft-based methods, since it has very little latency (and does not need too much cpu). bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] software license for pd general patch?
On 06/30/2010 06:12 PM, Mathieu Bouchard wrote: imho this would not be worth the effort, and a horrible idea to make deliberatly unreadable pd-patches... If you keep on saying things like that, I will make a patch obfuscator patch just so that the content of threads about obfuscation would shift away from hypothesis and towards real issues. That would be worth it, in terms of getting the debate to evolve past what pd-list was saying a decade ago or so. i meant using obfuscation (and making an obfuscatore for using it) is not worth it. if a obfuscated patch is very ingenious than it might make sense to spend the time to decipher it. if not, than it is easy to build everything yourself anyway. i have attached my proof of concept pd-obfuscator. (only random positioning, but adding deletion of comments and making cryptic names should be not too hard) it was quite easy indeed, and i learned that pd is not as bad for manipulationg strings as i thought it was. and i did not know before that the (quite powefull) list-objects are in vanilla(?).(they are not in (my) help-intro.pd) bis denn! martin #N canvas 610 118 799 745 10; #X obj 136 138 textfile; #X obj 38 -12 bng 15 250 50 0 empty empty load 17 7 0 10 -262144 -1 -1; #X msg 23 71 rewind; #X msg 82 70 read input.pd; #X obj 53 40 t b b; #X obj 292 32 bng 15 250 50 0 empty empty mess 17 7 0 10 -262144 -1 -1; #X obj 585 158 bng 15 250 50 0 empty empty save 17 7 0 10 -262144 -1 -1; #X obj 197 106 until; #X obj 84 511 list; #X obj 246 418 list split 2; #X obj 37 473 list; #X obj 83 446 pack f f; #X obj 81 419 random 500; #X obj 161 419 random 500; #X obj 517 555 textfile; #X msg 574 469 rewind; #X msg 629 467 clear; #X obj 84 380 t b b b l; #X obj 100 672 list split 1; #X obj 88 588 until; #X obj 56 631 list append; #X obj 198 647 bang; #X msg 457 447 add2 \$1; #X obj 120 557 t b a; #X msg 307 485 add; #X msg 584 377 write output.pd; #X obj 295 73 t b b b; #X obj 119 227 select #X; #X obj 119 197 list split 1; #X obj 73 348 list; #X msg 8 423 #X obj; #X obj 294 270 list; #X obj 115 279 list split 1; #X obj 110 304 select obj; #X obj 121 253 list; #X obj 134 160 t a a; #X obj 207 235 t b; #X obj 223 286 t b; #X connect 0 0 35 0; #X connect 0 1 7 1; #X connect 1 0 4 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 2 0; #X connect 4 1 3 0; #X connect 5 0 26 0; #X connect 6 0 25 0; #X connect 7 0 0 0; #X connect 8 0 23 0; #X connect 9 1 8 1; #X connect 10 0 8 0; #X connect 11 0 10 1; #X connect 12 0 11 0; #X connect 13 0 11 1; #X connect 15 0 14 0; #X connect 16 0 14 0; #X connect 17 0 30 0; #X connect 17 1 12 0; #X connect 17 2 13 0; #X connect 17 3 9 0; #X connect 18 0 22 0; #X connect 18 1 20 1; #X connect 18 2 21 0; #X connect 19 0 20 0; #X connect 20 0 18 0; #X connect 21 0 19 1; #X connect 21 0 24 0; #X connect 22 0 14 0; #X connect 23 0 19 0; #X connect 23 1 20 1; #X connect 24 0 14 0; #X connect 25 0 14 0; #X connect 26 0 7 0; #X connect 26 1 15 0; #X connect 26 2 16 0; #X connect 27 0 34 0; #X connect 27 1 36 0; #X connect 28 0 27 0; #X connect 28 1 34 1; #X connect 29 0 17 0; #X connect 30 0 10 0; #X connect 31 0 23 0; #X connect 32 0 33 0; #X connect 32 1 29 1; #X connect 33 0 29 0; #X connect 33 1 37 0; #X connect 34 0 32 0; #X connect 35 0 28 0; #X connect 35 1 31 1; #X connect 36 0 31 0; #X connect 37 0 31 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] software license for pd general patch?
On 06/29/2010 02:20 AM, João Pais wrote: Basically something that allows people to disseminate the program (even though is available online), but without them changing it (or not without my consent/knowledge). licence-wise you could use some properitary free(as in beer)-ware licence which is found in many freely donwloadable (closed source) software. or no licence at all, which means all rights reserved. (or just ask me) technically it is almost impossible to prevent people from building upon your work, though you could try some kind of code-obfuscation, like writing a little perl script which places all objects at random positions and gives cryptic names to subpatches and abstractions. imho this would not be worth the effort, and a horrible idea to make deliberatly unreadable pd-patches... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.42.5 release candidate 3 released!
the ~ and ~ etc. are not created, like in the previous versions. (linux/mac/win). this is id 1702883 in the bugtracker, but it happens on all os, not only osx. on windows i had a errormessage allocting font resource or something like that (sorry, i can not remember the exakt message), during the installation, but only the first time i installed. (maybe some remains of an older pd-extended installation interfered). after unistalling and reinstalling i had no errors. and on osx the icon looked strange. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problems Following Floss Generating Waveforms Article
Alex Lucas wrote: there doesn't seem to be any visible clipping on the table. The audible clipping was present across the frequency range but changing the multiplication on the phasor~ to 2048 has solved the problem. it is not so much clipping, but a discontinuity in the waveform, which produces the unwanted distortion. sinesum creates not exactly 1 cycle of the waveform, but also extra samples for the tabread4-interpolation. this is hardly visible (and audible) with big tables/low frequencys, but easiely visible with a small table (sinesum 40 1 for example), you can see that the waveform does not start and end at 0. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bit crusher abstraction
David Schaffer wrote: I'd like to know if there's a bit crusher/ lo-fi/ sonic destructor abs. a bit-reduction effect is quite easy to build: multiply the signal by a (larger) number, throw away the fractional part (by using expr~ int($v1), or building something with wrap~) and divide the signal by the same number. the higher the number, the 'smoother' (less crushed) the result. for 'authentic bit-reduction' you can use powers of 2, but numbers inbetween are also fine (imho often better sounding). there is something like that in my 'instrument collection' (quantizer.pd) http://www.martin-brinkmann.de/mnb_instruments_wip.zip bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problems Following Floss Generating Waveforms Article
Alex Lucas wrote: http://en.flossmanuals.net/PureData/GeneratingWaveforms Any help with this would be very much appreciated, it may just be my soundcard acting strangely. i think the artifacts (audible at higher frequencys) resulting from the phasor going from 0 to 2051. after changing this to 2048 the sound of both oscillators is similar. i think the 3 extra points in the wavetable are just for tabread4 interpolation, and should not be read (directly). bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Free samples somewhere on the net?
i often use sounds from the olpc project: http://wiki.laptop.org/go/Sound_samples there are also a few instrument-multisamples. and here are quite a lot samples of piano and orchester instruments: http://theremin.music.uiowa.edu/MIS.html bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] And finally... netbook recommendation
Jerome Covington wrote: Are there any recommendations on netbook/audio interface combinations for further development and performance using pd? i would recommend not to use a netbook, or any other atom-based system, because the performance with pd is rather poor. my aspire one with 1.6ghz does not come close to my old pentium m with 1.4 ghz. it feels more like a machine with about 900 mhz cpu. (i think this is caused by pd not making use of hyperthreading) latency of internalk sound is about 20 ms with oss on ubuntu karmic. (and a little lower, when i refrain from moving/opening other windows and no system update etc. is running in the background) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Smoother Audio than Pd?
Roman Haefeli wrote: you can find the major7.pd patch and its depencencies here: http://www.romanhaefeli.net/software/pd/ i could not find major7.pd there, but i have tried the bandlimited_oscilators (sinesum), which sounded quite a lot better/smoother than other methods for making bandlimited waveforms in pd. i will try to make some pad-synths with these. couldn't find that particular track on: http://noconventions.mobi/nvisible.taz/ some other ones are also very good, but that one was my favourite. looks like it is gone. i could send it to you by mail if you like, or put it (temporarly) on my site. or maybe the author of this music is also reading this list? bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Smoother Audio than Pd?
colet.patr...@free.fr wrote: didn't like the sonority of netpd for example, because rendered texture are poor, only one sytnh sound good the reason might be that netpd is 'pd-vanilla', and there are not so much techniques used for getting smooth(er) sound (afair), like bandlimited oscs and custom filters. without any further effort (or using externals), pd sounds pretty rough and 'digital'. (not so much like 'ice-cold fm-pads', more like '8-bit lofi with aliasing'.) a 'modern' version of netpd, using rjlib for example, might sound better. i think max/msp has a few more good sounding 'built-in'-objects than pd (i have only played a little with the demo version), and other systems, which are more high-level (reaktor, supercollider, csound) have 'good-sounding' modules out-of-the-box anyway. but i think it is possible to achieve similar quality with pd. it needs (quite a lot) more effort though... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Smoother Audio than Pd?
martin.pe...@sympatico.ca wrote: If a basic [osc~] sounds like 8 bits I think maybe you need a better sound card. ;) i did not mean that literally ;) and i like 'lo-fi-sound'. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Smoother Audio than Pd?
Roman Haefeli wrote: Actually, there vanilla-based bandlimited oscillators and some netpd-synths are using them. maybe the one good-sounding synth is one of them. and i remember some synths which use just phasor~-0.5 (which i also use quite often). bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] a good filter for my sample reader...
David Schaffer wrote: Idealy the device should be fat sounding and resonant... imho the nusmuk-audio-filters posted to the list a while ago are among the best sounding (pd vanilla) filters. only the cpu-load is very high, due to fexpr~. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] crazy bug: all user actions executed twice
Matteo Sisti Sette wrote: I write just to see if anybody has already seen this happaning happens here also sometimes. closing and reopening pd usually solves the problem. (ubuntu jaunty 32 bit, pd .42-5, gem loaded, but i think it happend also without gem) and can give me some clue as how to avoid it. unfortunatly not. it might have something to do with opening/closing large patches, but im not sure. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gp2xPd install issues
sorry, this is probably not very helpfull, but: Matthew Logan wrote: Has anyone had any issues with installing gp2xPd? I can't get this thing to work. it is runnig fine here on exactly the same device (f100b, 3.0.0) and i vaguely remember that i had a few issues with the installation, but unfortunately i do not remember what exactly the problem was. i have compared the directory on my gp2x with the downloaded tgz, and found no difference. I get a black screen for a few seconds then a white screen this is ok, and then some text, toggles and numbers should appear on the white screen. that lasts until I move the joystick, at which point it kicks me back to the GP2X menu. this looks like a patch is loaded, but something goes wrong afterwards(?) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Free/open mobile platform for Pd?
Otto Maddox wrote: Maybe it's just because I'm new to the world of mobile computing and have missed something, but I couldn't find a single mobile hardware/software platform which is properly Free/open from top to bottom (i.e., friendly to people who don't mind getting their hands dirty), actively maintained, doesn't require me to screw myself over by taking on a contract which I can't afford (internet tablet would be ideal), and runs Pd. Is PDa still being developed? i think a decent (with fpu) and completely free (like the neo/freerunner) device does not exist. but there are a few which are less unfree than the i-thing: as far as i have heard, rjdj is currently ported to android. the new nokia 900 uses also a more or less free system (maemo), and pd already exists for the older (fpu-less) maemo based web-pads. the zii-egg also uses a linux derivative, and should be able to run pd. maybe others. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Free/open mobile platform for Pd?
Hans-Christoph Steiner wrote: as far as i have heard, rjdj is currently ported to android. But not released, and likely not free. probably free as in beer only, but i hope it does not take too long until it is released. What's non-free about Maemo? I use a Maemo device daily and as far as I can tell its as free as Ubuntu (there might be some binary blobs, but there might not). i meant the non-free binaries, and i am not sure how the telephon-functionality is integrated in the new maemo version. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Free/open mobile platform for Pd?
Hans-Christoph Steiner wrote: as far as i have heard, rjdj is currently ported to android. But not released, and likely not free. probably free as in beer only, but i hope it does not take too long until it is released. AFAIK, they wanted to keep the core rjdj app a free download, but Apple doesn't allow you to sell media for apps that are free (rjdj sells albums of pd patches). So now rjdj is only free as in beer if you have a jailbroken phone. yes, according to their website, the in-app-sales are only allowed for paid apps. (you can buy commercial scenes/download free scenes (pd-patches) from the rjdj-application) but only on the iphone/pod. i hope the android-version will be free (beer) again. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problems with DIO errors / audio clicking
James Dunn wrote: Can anyone help? probably not. i have had the same problems since i upgraded from hardy. i had more or less periodic clicks/dropouts and erros, especially whith heavy gui activity. (minimizing the gui while recording helped a little) i have given up, and use oss instead of jack now. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GGEE [lowpass] error vs. purepd [lowpass]? was Re: basic resonant filters in Pd
brandon zeeb wrote: Can you reproduce this behavior on your machine? no, both filters sound exactly the same here. with 44100 samplerate though. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] basic resonant filters in Pd
Derek Holzer wrote: VANILLA PD *SIGNAL CONTROLLED* vcf~ moog~ is moog~ really in vanilla? (not here (0.42-5), unforunately, though i think it should be...) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Good sequencer patches for learning?
Solen Music wrote: my plan for the tappable groove metro is not to use [metro] but to keep a variable table of times between output bangs. i hope to hook two drum pads to a [timer] based kind of bpm counter. one pad will input the downbeat times and the other the offbeat times (the usual decider in 'swing-factor'). if that makes sense?!? i think it makes sense, though, if i understood everything right, the drummer has to consciously tap the groove (but that is of course also true for the usual tap-tempo-button). an 'automatic groove recognition' (getting the tempo from what the drummer is normally playing) would be great... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Good sequencer patches for learning?
Solen Music wrote: I did mean step sequencer. i have allways been interested in step-sequencers, and made a few attempts to build a good one. of course i was not successfull in making the perfect step-sequencer... and i would not reccomend my creations for learning, since they are quite messy, and rather designed for my own needs, than for beeing 'good examples'. (i want things to be as self contained as possible (no abstractions), and 'hassel-free copy/pasteable') anyway, you can find some basics like the use of counters, select/route etc. also in my patches. www.martin-brinkmann.de, my_instruments, and i think the latest is called sequencers1. sequencer that runs off a tappable groove metro (to give the option of everything from rigid straight to super loose hand tapped swing). this sounds interresting. i have wondered a few times how to make something like that, but was not able to come up with something better than a tap-tempo with a simple 'swing-factor'. how does your groove-metro work? bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM on Linux netbook
Ben Baker-Smith wrote: -Does the netbook have enough processing power for general GEM applications? I'm usually not dealing with video files, but rather particle generation, shape manipulation, GIF texturing, and audio-response. On my Macbook (2.0 GHz intel processor) the CPU meter always shows below 50% usage i think you can expect a pd patch wich runs at 50 percent on a 2 ghz dualcore machine, to use about 200 precent on the atom-cpu. my patches which need about 60 percent on my old pentium m, 1.4 ghz, use 130 percent on the a110. -Are there any other issues that you think of given this scenario? and if so, what other affordable/really-cheap laptops are there out there that I can run linux on? i would try to get a used intel notebook, if (small) size does not matter that much, and google if it is known to run linux well. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] biquad~ with elementary filters [was: Re: dinosaurs ...]
Damian Stewart wrote: [shrug] i don't even know what a 'zero' is. a (probably a little too simple) explanation: a zero is a valley. its depth is 0 on its deepest point. a pole is a very (very,very,...) high mountain. both things exist on the complex plane (just a plain, where all points have 2 coordinates, like any map) you can design filters by placing (defining a pair of coordinates) poles and zeros within the unit circle (a circle with radius==1 around the origin (center) of the complex plain). the frequencys from zero to samplerate/2 are wrapped around the upper half of the unit circle. when you cut along this line through your 'landscape', the profile is the same as the graph on your filter/eq plugin. for example the peak-filter from the pd docs is just a 'mountain' and a 'valley' which are moved on circular pathes with a certain distance to the unit circle. the closer the 'mountain' is to the unit circle, the higher the peak (on the circular profile-cutout). the frequencys coressponding to this spot are boosted. the position on the path (or the angle) defines the frequency. so it is possible to make filters with the cpole/zero objects, without knowing too much (or anything at all...) of the math involved. the only problem i still have, is the gain-factor. while this is easy to overcome with 'static' filters (just scale the filters input or output until it is loud enough/stops clipping), i have not yet found a method (that works without thinking (and more important: computing) too much) for time-variable-filters. ok, a table would do the trick, but thats not elegant at all... bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] biquad~ with elementary filters [was: Re: dinosaurs ...]
Frank Barknecht wrote: that is true, but it looks like no one has made a (usual lp,hp,etc.) filter with these objects until now. Except Miller. [1] you are right, there are some usual filters made with pole/zero objects, the shelving and peaking ones, a nonresonant lp and a bp, iirr. and the examples in millers book have been very helpfull with my own attemps to make a resonant lowpass. but the standard filters (resonant 2,4 pole lp,hp,bp,notch,...) for sound synthesis do not exist (yet) in vanilla-pd. Though I agree that some more of these would be handy. I tried to make a biquad~ clone with the elementary filters, but failed so far. I assume from [2] that the transfer function of two rzero~ and two rpole~ in series should be the same as a biquad~, however I don't know how to convert the ff1, ff2, ff3, fb1 and fb2 coefficients of biquad~ into the coefficients to use at the second inlets of the elemetary filters. Can anyone help? i had the same problem, and did not find a solution. (it might be quite complicated anyway), so i tried to build a filter by directly placing the pole and zero. it sounds not bad, but i still have a problem with scaling the output correctly. if i use this filter in a synth i have to adjust the volume quite often. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] filtering: a lowpass resonant filter
Damian Stewart wrote: to answer my own question: use [biquad~] with coefficients taken from the [lowpass] external. i while ago i have tried to build a resonant lp with biquad~, but had problems with clicks, when the coefficient were changed (even with quite slow changes). only very slow changes did not produce clicks, which is a little strange, since biquad-filters in my vst-plugins do not produce any clicks (and i compute the coefficients only every 96 samples or so (iirr), i use the other biquad form though. i had better luck with the cpole/zero~ objects, the result sounded at least like a resonant lp, good enough for a little squelchy bassline synth. though i still have not found out how to calculate the a0 (volume level scaling) coefficient right (and i could not get hold of the book that was reccomended on the list yet) bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems with pd extended (0.40.3)
Si Mills wrote: I've been using [expr~ ] as a workaround eg. [expr~ $v10.5] ok, it is good to know that there is a workaround, and i will probably use the expr-method in the future for compatibility with 'pd vanilla'. but i am not looking forward to converting all my patches... thanks for your hint! bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] problems with pd extended (0.40.3)
hi! i'm sorry if this has been asked (and answered) before, but i have not found a solution yet. (in the list archive) ~ ~ (and maybe other signal operators from zexy) are not created. is there a workaround? vcf_hp2~ throws an iem_cot~... couldn't create, but only if not vcf_hp4~ (or some other iem-lib filters, i suppose) have been created before. bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] splitfilename length problem
hi list! i have a problem with iem-lib (r 1.15 (the most recent one, i hope)) splitfilename: names wich are exactly 76 characters long cause pd to freeze (see attached example). is this a known/fixed bug? i could not find anything in the archive or on the net. and is there a workaround (or an alternative to splitfilename)? (other than finding out the symbols length and adding a whitespace if its 76 ;) (in my case i need splitfilename only for displaying sample names)) bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] splitfilename length problem
IOhannes m zmoelnig wrote: coud you (re)attach the example? oops, sorry! i have clicked send a little too early... you can use zexy's [symbol2list] for such things as well. thanks, i will take a look at it. bis denn! martin #N canvas 481 272 608 289 10; #X obj 15 217 splitfilename; #X obj 106 244 print; #X text 478 79 freeze pd!!!; #X msg 44 76 symbol qwertzuiopasdfghjklyxcvbnmqwertzuiopasdfghjklyxcvbnmqwertzuiopasdfghjklqasdf ; #X connect 0 1 1 0; #X connect 3 0 0 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] splitfilename length problem
Hans-Christoph Steiner wrote: That's a new one for me, sounds pretty crazy. it was related to my outdated (1.15) iem-lib binary. i have just tested with current pd extended version, and copied the latest (r 1.17) iem-lib ito my current pd installation, and the problem (quite crazy indeed) is gone. bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] splitfilename length problem
Steffen Juul wrote: It doesn't freeze in Pd-extended 0.39.3 (mac osx). No idea what version of iem-lib that is though. it seems that it only happend with my old iem-lib version. installing the latest one (1.17) solved the problem. bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] splitfilename length problem
Ctrl Alt Back wrote: Works ok on debian Pd version 0.41.0-extended-20071107. works with recent version of the iem-lib, it seems that it only happend with old iem-lib versions, maybe only with old iem-lib + new pd version. thanks for checking to everyone! sorry for any inconvenience. bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] poles, zeros and gain
Isidro Gonzalez wrote: so is it possible to get the gain from the poles and zeros, without calculating all coefficients? Of Course it is. You must evaluate the transfer function of the filter in the unit circle. For a nice explanation on how to do this and some C code samples, see: Elements of Computer Music by F. R. Moore, Cap.1 pp. 119-133 thanks for the hints. i will see if i can find this book somewhere. bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] poles, zeros and gain
hi pd-list! i have recently tried to build some filters using cpole and czero, not completely unsuccessfull (at least the lowpass sounds somewhat like a lowpass...), but i have a problem calculating the right gain (or attenuation) factor. for the lp it seems to work more or less (ok for a subtractive synth, but still not good enough for effects etc.), but the hp is either too lound for lower frequencies and low resonance, or hardly audible. i think there might be a better way to find out the right gain than 'try and error'. and its getting worse with more poles involved... so is it possible to get the gain from the poles and zeros, without calculating all coefficients? bis denn! martin #N canvas 156 137 470 338 10; #X obj 82 263 dac~; #X floatatom 1 8 5 0 0 0 - - -; #X obj 235 4 hsl 128 15 0.05 0.99 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 4700 1; #X text 229 -16 res; #X text 91 -17 cut; #X obj 93 1 hsl 128 15 0 128 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 5600 1; #X obj 162 143 mtof; #X obj 3 47 phasor~ 222; #N canvas 190 170 920 635 simple_reson_lp1 0; #X obj -19 398 cpole~; #X obj 31 440 czero~; #X obj 27 494 outlet~; #X obj -173 141 inlet~; #X obj -53 364 *~; #X obj 31 118 /~ 2; #X obj 32 238 cos~; #X obj 95 182 -~ 0.25; #X obj 96 203 cos~; #X obj 96 256 *~; #X obj 225 183 clip~ 0.05 0.99; #X obj 236 146 inlet~; #X obj -60 305 *~; #X obj -81 266 +~ 2; #X obj -84 237 *~ 0.5; #X obj -27 279 -~; #X obj 32 90 clip~ 0 1; #X obj 36 34 /~ 11025; #X obj 34 5 inlet~; #X text -123 141 audio in; #X text 81 5 cutoff; #X text 287 143 resonance; #X text 55 368 zero at nyquist; #X text 99 35 1/4 samplerate; #X text -128 198 attenuation factor; #X text -128 214 (1-x)*(1/2*angle+2); #X text 70 118 pi/2 for audio cos; #X text -256 396 pole: cos(angle) \, sin(angle)+res; #X text 39 220 cosine; #X text 147 191 sine; #X text -310 363 multiply input by attenuation factor; #X text -404 106 4/2008 martin brinkmann; #X text -405 8 slightly crude (especially the attenuatiun factor) lowpass filter design \, made without knowing too much of the math involved. frequency is not very exact \, but at least it sounds like a reson filter :-); #X text -404 63 a pole is moved along the unit-circle on a kind of rugby-egg-shaped path \, while a zero sits at -1 \, 0 (nyquist frequency) \, which makes a resonant lowpass filter.; #X text 100 54 cutoff (or angle on the unit circle \, usually 0..pi (0..nyquist) \, but here 0..0.5 because of the cos~ audio object); #X obj -32 246 sig~ 1; #X obj 45 393 sig~ -1; #X obj 104 393 sig~ 0; #X connect 0 0 1 0; #X connect 0 1 1 1; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 4 0 0 0; #X connect 5 0 7 0; #X connect 5 0 6 0; #X connect 6 0 0 2; #X connect 6 0 15 1; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 0 3; #X connect 10 0 9 1; #X connect 11 0 10 0; #X connect 12 0 4 1; #X connect 13 0 12 0; #X connect 14 0 13 0; #X connect 15 0 12 1; #X connect 16 0 5 0; #X connect 16 0 14 0; #X connect 17 0 16 0; #X connect 18 0 17 0; #X connect 35 0 15 0; #X connect 36 0 1 2; #X connect 37 0 1 3; #X restore 102 192 pd simple_reson_lp1; #X connect 1 0 7 0; #X connect 2 0 8 2; #X connect 5 0 6 0; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 0 0; #X connect 8 0 0 1; #N canvas 69 503 470 338 10; #X obj 82 263 dac~; #X floatatom 1 8 5 0 0 0 - - -; #X obj 235 4 hsl 128 15 0.05 0.99 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 4500 1; #X text 229 -16 res; #X text 91 -17 cut; #X obj 93 1 hsl 128 15 0 128 0 1 empty empty empty -2 -6 0 8 -262144 -1 -1 12400 1; #X obj 144 81 mtof; #X obj 3 47 phasor~ 222; #N canvas 167 157 920 635 simple_reson_hp1 0; #X obj -19 398 cpole~; #X obj 49 519 czero~; #X obj 49 591 outlet~; #X obj -173 141 inlet~; #X obj 31 118 /~ 2; #X obj 16 184 cos~; #X obj 95 182 -~ 0.25; #X obj 96 203 cos~; #X obj 96 256 *~; #X obj 225 183 clip~ 0.05 0.99; #X obj 236 146 inlet~; #X obj 33 34 /~ 11025; #X obj 34 5 inlet~; #X text -123 141 audio in; #X text 81 5 cutoff; #X text 287 143 resonance; #X text 99 35 1/4 samplerate; #X text 70 118 pi/2 for audio cos; #X text -256 396 pole: cos(angle) \, sin(angle)+res; #X text 29 167 cosine; #X text 147 191 sine; #X text -310 321 multiply input by attenuation factor; #X text 100 54 cutoff (or angle on the unit circle \, usually 0..pi (0..nyquist) \, but here 0..0.5 because of the cos~ audio object); #X text 55 368 zero at zero frequency; #X obj -59 222 -~; #X obj -45 327 *~; #X obj -92 181 sig~ 1; #X obj 49 392 sig~ 1; #X obj 99 393 sig~ 0; #X obj 32 94 clip~ 0 0.5; #X connect 0 0 1 0; #X connect 0 1 1 1; #X connect 1 0 2 0; #X connect 3 0 25 0; #X connect 4 0 6 0; #X connect 4 0 5 0; #X connect 5 0 0 2; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 0 3; #X connect 9 0 8 1; #X connect 9 0 24 1; #X connect 10 0 9 0; #X connect 11 0 29 0; #X connect 12 0 11 0; #X connect 24 0 25 1; #X connect 25 0 0 0; #X connect 26 0 24 0; #X connect 27 0 1 2; #X connect 28 0 1 3; #X connect 29 0 4 0; #X restore 101 192 pd
Re: [PD] timestretching for slicer
a while ago i have built a little, 'quick and dumb' beatloop
which uses not exactly the same techniques used in live (it is
missing the tempo-warp-stuff), but does basicly the same thing as
reaktor and acid do. without any analysis though, so
transients are not taken into acount. i have built this one because
i was unhappy whith the soundquality of a 'rockafella'-based
aproach, at least when using percussive loops.
in short it is: cut a loop into 1/16 (or whatever)
slices, and trigger these slices on every 1/16.
sounds not much worse then live (1.x), within
a reasonable tempo range.
i think live uses quite a similar method in its 'beat-mode'.
maybe with a little sample-analysis for finding ideal (or at
least better) start- and loop points (instead of just
playing on) for the 'grains'. 'warping' could possibly be
implemented with a variable bpm...
the other live-modes are probably something similar to
the 'rockafella'-method, and something 'graincloud'-like
('texture'-mode). newer versions of live include also a
frequency-domain based method, but i have not yet heard
this one.
since it is not very big, i hope it is ok to
attach the patch. (sorry, a little messy as
usual ;-))
bis denn!
martin
#N canvas 162 38 468 508 10;
#X obj 18 189 dac~;
#X obj 17 21 loadbang;
#X msg 17 46 120;
#N canvas 105 38 1142 827 beatloop1 0;
#X floatatom 295 108 3 0 0 0 - - -;
#X obj 128 114 hsl 160 8 3 128 0 1 empty empty olen -26 4 0 8 -262144
-1 -1 1700 1;
#X obj 392 -79 int;
#X obj 323 128 hsl 64 8 0 1 0 0 empty empty empty -2 -6 0 8 -262144
-258699 -1 3544 1;
#X obj 278 -205 + 1;
#X obj 227 -209 float;
#X obj 278 -151 mod;
#X obj 198 -410 inlet;
#X obj 353 -318 inlet;
#X text 238 -409 -bpm;
#X text 393 -318 -reset/sync;
#X msg 199 -367 1;
#X obj 223 -343 /;
#X obj 196 -388 t f f;
#X obj 228 -318 * 15000;
#X obj 341 -267 t b f;
#X obj 223 -240 metro 125;
#X msg 347 -292 -2;
#X text 147 -318 1/16 in ms;
#X text 168 -208 counter;
#X obj 100 290 outlet~;
#X obj 372 -123 mod 2;
#N canvas 0 27 1249 889 sample 0;
#X obj 92 430 soundfiler;
#X obj 71 284 openpanel;
#X obj 362 306 loadbang;
#X obj 383 112 bng 15 250 50 0 empty empty load 0 -6 0 8 -262144 -1
-1;
#X obj 109 240 splitfilename;
#X msg 103 454 set \$1;
#X msg 102 503 0;
#X obj -247 177 inlet;
#X obj 468 1147 outlet~;
#X obj 41 342 t b b a;
#X obj 319 342 t b b;
#X msg -46 712 0;
#X obj 130 610 pack;
#X obj 239 489 / 44.1;
#X msg 143 674 0 0;
#X msg 147 635 set \$1 \$2;
#X obj 178 545 *;
#X obj 201 468 t b f b;
#X msg 554 403 1.05946;
#X obj 560 432 pow;
#X obj 544 339 * -1;
#X obj 44 981 *~;
#X msg -13 680 -1 17.8636;
#X obj 250 108 hsl 128 8 100 160 0 1 empty empty dc -16 4 0 8 -262144
-1 -1 5300 1;
#X obj -24 944 *~;
#X obj 0 292 dbtorms;
#X obj -143 345 moses 0.001;
#X obj -135 685 pack;
#X obj 250 120 hsl 128 8 100 150 0 1 empty empty at -16 4 0 8 -262144
-1 -1 6900 1;
#X obj -123 305 dbtorms;
#X msg -131 751 1 22.8175;
#X msg -131 719 set \$1 \$2;
#X obj -73 454 t b b f;
#X obj -24 567 * -1;
#X msg -7 635 set \$1 \$2;
#X obj -4 606 pack;
#X obj -18 913 +~;
#X text -130 888 attack;
#X text 49 882 release;
#X obj 591 203 inlet;
#X obj 543 367 t b f;
#X msg 71 652 0;
#X obj 41 543 delay 1;
#X obj 41 566 t b b;
#X obj 400 182 inlet;
#X obj -152 201 inlet;
#X text 635 202 tp (semitones);
#X text -206 176 trigger/vel (0..1);
#X obj 123 536 *;
#X msg 36 597 set \$1;
#X obj 169 580 *;
#X obj 302 625 -;
#X msg 291 592 1;
#X text -111 202 duration (ms);
#X obj 276 546 t b b f;
#X obj 373 427 float;
#X msg -224 409 bang;
#X symbolatom 102 114 18 0 0 0 - - -;
#X text 442 183 sample start (percent);
#X obj 346 492 / 100;
#X msg 238 200 set symbol \$1;
#X obj 293 241 t b a;
#X obj 469 1112 +~;
#X obj -223 436 delay 1;
#X obj -290 103 inlet;
#X obj -278 250 pack;
#X obj -278 272 route 0 1;
#X obj -192 238 pack;
#X obj -192 260 route 0 1;
#X obj 398 221 pack;
#X obj 398 243 route 0 1;
#X obj 569 233 pack;
#X obj 569 255 route 0 1;
#X msg 966 504 0;
#X msg 828 713 0;
#X obj 1004 611 pack;
#X obj 1113 490 / 44.1;
#X msg 1017 675 0 0;
#X msg 1021 636 set \$1 \$2;
#X obj 1052 546 *;
#X obj 1075 469 t b f b;
#X msg 1295 374 1.05946;
#X obj 1292 408 pow;
#X obj 1285 310 * -1;
#X msg 861 681 -1 17.8636;
#X obj 764 402 moses 0.001;
#X obj 745 683 pack;
#X msg 743 752 1 22.8175;
#X msg 743 720 set \$1 \$2;
#X obj 801 455 t b b f;
#X obj 850 568 * -1;
#X msg 867 636 set \$1 \$2;
#X obj 862 605 pack;
#X obj 856 914 +~;
#X text 744 889 attack;
#X text 923 883 release;
#X obj 1284 338 t b f;
#X msg 945 653 0;
#X obj 915 544 delay 1;
#X obj 915 567 t b b;
#X obj 997 537 *;
#X msg 910 598 set \$1;
#X obj 1043 581 *;
#X obj 1176 626 -;
#X msg 1165 593 1;
#X obj 1150 547 t b b f;
#X obj 1232 443 float;
#X msg 770 433 bang;
#X obj 1220 493 / 100;
#X obj 735 512 delay 1;
#X text 625 553 2nd voice -;
#X obj 953 959 *~;
#X obj 1018 798 vline~;
#X obj 166 786 vline~;
#X obj 48 862 vline~;
#X obj -107 862 vline~;
#X obj 764 861 vline~;
#X obj 921 863 vline~;
#X msg 160 275 set read -resize
Re: [PD] probles with 0.39.2-extended-rc2 on windows
Steffen wrote: Isn't this much like what you/we talked about late november last year wrt. your groovbox patch? This rings a bell that's why, please check if it's related to this bug report, which, i think, boils your problem from last year down to a simple example: http://sourceforge.net/tracker/index.php?func=detailaid=1607030group_id=55736atid=478070 yes, i belive it is somehow related, but it happens also when the subpatch is not open. bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] probles with 0.39.2-extended-rc2 on windows
Hans-Christoph Steiner wrote: -the crashes when closing complex patches seem to happen more often compared to the linux version. If you can narrow this down, please post a bug report, hopefully with a example patch, to the bug tracker: maybe it is just not true that the 'crash on windowclose' happens all the time under windows: right after writing my last mail i had a series of such crashes under linux, and today i can only reproduce this behaviour under windows whe i change something in a relatively big patch. load my 'groovebox1'-patch, remove/and re-add a connection, close the window, and pd crashes. (on a samsung x10 laptop running winxp sp2). - sometimes pd throws a 'SIMD' message on the console. though it looks like this does not do any harm. I think it's from Gem. i had this messages also before i discovered the .reg file for setting the path-defaults. and gem was not loaded. PDP has not been ported to Windows, that explains why it is not there. perhaps you would like to do it? =D maybe later this century. ;) -there is something strange with the cpu-load display. my patch which is the most heavy on the cpu, gets about 49 percent on my linux machine (dualcore athlon 3800+), but on my wintel laptop (singlecore pentium m, 1,6 ghz) it jumps between 7,9,23 percent. If you have patch that illustrates this, that would be very helpful. Please file a bug report if you make such a patch and attach it. it happens with all patches. on my (faster(?)) linux-box the (displayed) cpu-load is about 1.5 times higher, and stays relatively stable at this value, while on the windows-laptop it constantly changes between lower and higher values, but the average is clearly lower than the value on linux. maybe i should build something to max out the cpu to see which computer is really faster... bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] probles with 0.39.2-extended-rc2 on windows
please apologize if this is not the right list to report problems with pd-extended. i have just tried pd extended on windows, and encountered the following problems: -iem abs vcf_hp2,4,6,8 are missing (i copied these from my linux installation) -iem_cot missing, used by vcf_hp2 and vcf_lp2 (i changed that to cot4 in the abs and it seemd to work fine). this was probably also the cause of the problems i had with a nightly build of pd extended a while ago under linux. -library path are not set by default/by the installer? -the crashes when closing complex patches seem to happen more often compared to the linux version. - sometimes pd throws a 'SIMD' message on the console. though it looks like this does not do any harm. -pdp is not included? -there is something strange with the cpu-load display. my patch which is the most heavy on the cpu, gets about 49 percent on my linux machine (dualcore athlon 3800+), but on my wintel laptop (singlecore pentium m, 1,6 ghz) it jumps between 7,9,23 percent. apart from that, all of my patches i have tried worked fine (excluding the ones relying on pdp). bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd and jack, informal survey
James wrote: i'd like to take an informal survey. is it true that you can do no serious work with puredata using the jack audio server for linux and mac os x? no, i have no major problems with jack (jackd 0.100.0) pd (0.39-2) on linux (ubuntu dapper), using a m-audio 2496 soundcard. though i get clicks and crackles (and pd dio erros) when the latency is set quite low, and the pd-patch uses a lot of gui elements, or when i drag windows etc. (afaik this is more a general problem of the pd gui). when recording i set the latency to soemthing about 20 ms to be on the safe side. i do not use much other software at the same time, only pd, mhwave for recording and eventually seq24. (or jamin mhwave, without pd) another strange problem with jack: after running qemu or dosbox, i get the delay exceeds estimated spare time messages when jack runs in realtime mode, but only about every 3rd oe 2nd time. the only solution i have found so far is to reboot. (that feels very win95 ;-)) bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] up-down saw-wave
Frank Barknecht wrote: difference between both is illustrated in attached patch. thanks, ok, i think i will use metro in most future pd-sequencer patches, instead of my old phasor-method... it was a 'quick-and-dirty' solution anyway, since i have sampled the phasor with metro 3 or 2 and snapshot (so there would have been no benefit from the audio-phasor), i thougt something like the 200 hz 'control-rate a la reaktor' would be sufficient. maybe the main reason for using the phasor was, that i had read something about timing-issues with the metro object. (i can not recall it exactly...) bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] up-down saw-wave
threen wrote: im not defending/attacking anything ... its just the fact that the analog cliped signal sounds much more convincing when comparing with digital hysteria hmm, yes, maybe. i think it depends on the context where the sound is used... btw: are there any good saturation/distortion patches? i have tried it with a table, but it souned not very convincing, so i have used simple clipping instead. bis denn! martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
