Re: [PD] moog~ in pure pd?

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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"

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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] editing pd silence

[martin brinkmann]

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] very compressed chip sounds

[martin brinkmann]

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~ $v1>>6&$v1&($v1*$v1>>14)+4095>>$v1;
#X text 254 64 expr~ $v1&($v1>>4)>>3&$v1>>7;
#X text 255 81 expr~ $v1&($v1>>7)|($v1>>4);
#X text 255 99 expr~ $v1&696969*(sin($v1>>10));
#X text 256 118 expr~ $v1<<(cos($v1&($v1>>7)))|($v1>>8)|($v1<<51|$v1<<32)
;
#X text 256 136 expr~ $v1>>4|$v1>>11&1234<<(($v1*1.5)>>($v1>>7));
#X obj -56 282 expr~ ((($v1&0xff)^0x80)-128)/128;
#X text 259 10 expr~ $v1*(($v1>>12|$v1>>8)&63&$v1>>4);
#X text 494 9 default;
#X obj -59 185 expr~ $v1>>4|$v1>>11&1234<<(($v1*1.5)>>($v1>>7));
#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

[martin brinkmann]

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*(($v1>>12|$v1>>8)&63&$v1>>4) & 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

[martin brinkmann]

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

[martin brinkmann]

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:
> 

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

[martin brinkmann]

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

[martin brinkmann]

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] very compressed chip sounds

[martin brinkmann]

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] Appending two signals together to create a third

[martin brinkmann]

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] Appending two signals together to create a third

[martin brinkmann]

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] making puredata headphone-safe

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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] I wanna sing like Paris

[martin brinkmann]

On 08/17/2010 11:25 AM, Pierre Massat wrote:
> I have never tried autotune. I gather from what you wrote that it can be
> used in realtime?

yes, it adds only very little latency

> I always thought the signal was split in two
> parts, one used to analyse the spectrum, and one to analyse the pitch. In
> this model the pitch would be modified according to some rules and the
> timbre would be stamped back on it. That's what it sounds like to me, but i
> may be mistaken to a great extent.

i am not shure either. probably you (and wikipedia) are right,
and autotune uses a phase-vocoder. using millers phase-vocoder with
small window-sizes sounds awfull though. but maybe, with
waves which are already periodic (like single cycles) it is possible
to do without windowing and short fft sizes (like 128 or even 64).
i will try this when i have found a way to extract
single-cycle waves from audio input in pd...

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

[martin brinkmann]

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] simple complex FM-Synthesis with pure Data

[martin brinkmann]

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] software license for pd general patch?

[martin brinkmann]

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?

[martin brinkmann]

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!

[martin brinkmann]

On 06/15/2010 09:54 PM, Hans-Christoph Steiner wrote:

>> 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.
> 
> Which version of Windows?

xp, sp3.

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!

[martin brinkmann]

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] bit crusher abstraction

[martin brinkmann]

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

[martin brinkmann]

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] Problems Following Floss "Generating Waveforms" Article

[martin brinkmann]

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?

[martin brinkmann]

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

[martin brinkmann]

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?

[martin brinkmann]

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?

[martin brinkmann]

Roman Haefeli wrote:

> Here's a minimal track also made with Pd, for the sake of diversity:
> http://www.netpd.org/sessions/2007-11-08_antiwecker.mp3

thats a cool track! and there are a few more on the server.
i am just listening to "hinsichtlich", and i really like
the pad-sound which starts at about 3:00 (right after this
'distortion accident'). can you tell me what patch it is?

> Is it time for having a pool for Pd-made music?

a while ago there was a "music made with pd" topic on this list,
and there where some good examples posted. i remember especially
a track called "post" by "daax", which i like very much.
(nice pads and sample treatment vs. super-harsh percussion)

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 brinkmann]

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] Max Smoother Audio than Pd?

[martin brinkmann]

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?

[martin brinkmann]

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] a good filter for my sample reader...

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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?

[martin brinkmann]

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] Free/open mobile platform for Pd?

[martin brinkmann]

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?

[martin brinkmann]

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] Problems with DIO errors / audio clicking

[martin brinkmann]

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] Pd-extended 0.41.4-rc4 released!

[martin brinkmann]

Hans-Christoph Steiner wrote:

> http://at.or.at/hans/pd/installers.html
> 
> I think its ready for release, so please try it if you haven't already
> so we can find the last bugs.

zexys >~, ==~, etc. objects are not created (for example in the
zexy help patches). i found this is already marked as 'open' in
the bugtracker, but only fort osx. it happens here in
ubuntu 9.04 too.

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

[martin brinkmann]

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

[martin brinkmann]

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?

[martin brinkmann]

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?

[martin brinkmann]

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

[martin brinkmann]

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 ...]

[martin brinkmann]

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 ...]

[martin brinkmann]

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

[martin brinkmann]

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)

[martin brinkmann]

Si Mills wrote:
 > I've been using [expr~ ] as a workaround
>
> eg. [expr~ $v1<0.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)

[martin brinkmann]

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

Re: [PD] splitfilename length problem

[martin brinkmann]

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] splitfilename length problem

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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

[PD] splitfilename length problem

[martin brinkmann]

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] poles, zeros and gain

[martin brinkmann]

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

[martin brinkmann]

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 

Re: [PD] timestretching for slicer

[martin brinkmann]

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 -resi

Re: [PD] probles with 0.39.2-extended-rc2 on windows

[martin brinkmann]

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:
> 
> 
>  

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

[martin brinkmann]

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

[martin brinkmann]

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

[martin brinkmann]

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] analogue clipping

[martin brinkmann]

hard off wrote:
> what's the best and most cpu efficient way to clip a signal in an
> analogue fashion, rather than getting nasty digital distortion?

i have used the function x/abs(x+a) applied to the audio input, and it
sounded quite ok. a controls the 'steepness' of the 
'distortion-function', good values are between 0.1 and 0.8.

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

[martin brinkmann]

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

Re: [PD] up-down saw-wave

[martin brinkmann]

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

[martin brinkmann]

Frank Barknecht wrote:

...

thanks for the many tipps!

> In the long run you could save quite some CPU cycles by using the more
> traditional clock-based sequencing where possible.

in the past (reaktor) i have used the songposition most of the time, and 
made everything counter-based. (always perfectly in sync,

but harder to manually re-sync).
since i was happy that my first pd patch (a 'rockafella'-based
loop-player) was running pretty well (and in sync) with this
pahsor based approach, i continued to use this method. i agree that it 
is a waste of cpu. maybe id would be a good idea to use only one phasor

(or a vline based 'phasor') to drive a counter and than use this
counter for the different sequencers. at least when it is not
neccessary to sync the different modules independently.
(groovebox2...)

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

[martin brinkmann]

Steffen wrote:

Works here too (osx i386 pd-extended). It was great fun trying to figure 
how they worked i the user end (i didn't complete, but got some stuff 
straight).


thats good news, sice i tried it once with a nightly build of
pd extended, and could not get the groovebox to work. it only
produced a lot of "'' expected but got bang" error-messages, and
since jack-audio-out did not work either i de-installd pd-extended,
and went back to pd 0.39 (the one from the ubuntu 6.06 repository)

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

[martin brinkmann]

threen wrote:

> nice indeed... but still, the attack on those synths/filters cant be
> compared with analog...

you are right, and i should have written 'subtractive' instead
of 'virtual analog'. it is just my first, naive attempt to make such a 
synth in pd, and i have not cared at all for any authentic analog

emulation. though i like the kind of 'rough' digital sound, i will
probably try to make bandlimited oscs, use upsampling etc. in the
future.

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

[martin brinkmann]

Max Neupert wrote:


I like the funky groovebox, and the others as well.


awsome presets in the groovebox. sounds like afx analord...
nice.


it is nice to hear that you like them. and it is also nice
to hear that my patches seem to be working on other peoples
systems too. though i have a slight problem, especially
with the groovebox-patch myself:

sometimes, when i close the patch (especially when i have
opend some subpatches before), not only the groovebox is closed,
but also all other open windows + the pd application. this has
also happend with 'grainstates', but less often. it might have
something to do with using (too) many ui-objects, and/or with
my relatively slow machine (?)

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

[martin brinkmann]

sorry, i could not reply earlier, because i had no internet
for about 2 days. (thanks t-...)

Frank Barknecht wrote:

http://www.martin-brinkmann.de/pd-patches.html 
I like the funky groovebox, and the others as well.


(The subpatches could profit from an interior decorator, though. ;)


i agree that my patches look pretty messy. though this is mainly because 
i am lazy ;), but i also try to avoid a 'misleading layout', where the 
objects are all aligned orthogonally, and it is sometimes hard to tell

wether the left or right inlet is connected for example.

using more subpatches/abstractions would probably help...

bis denn!
martin

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list