Re: [PD] [PD-announce] KnobsAndSlidersDS
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote: On Wed, Feb 28, 2007 at 08:39:46AM +0100, Frank Barknecht wrote: I thought about this a bit more: Maybe it would be sufficient if the hit area of the slider's bar would be a bid bigger. Jump also probably is cool. But I'm not sure if it really would good if the movement wouldn't stop when the stylus leaves the slider area. The double negatives in this sentence are confusing me. :) I think what you mean is if the stylus is moving outside of the slider area, there will be no effect on the slider. I think that's probably a good idea as long as it doesn't let go of the slider. So if you move back inside the area, it will continue to have an effect. Yes, that's what I meant to write. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] strange behavior of splitfilename
Matthias Blau wrote: Hi list, in the attached patch I supply a filename from savepanel to splitfilename. This works as expected *except* if I happen to choose decay as filename, in which case pd crashes. Any help? this is a known bug in splifilename, which i think is fixed in the latest and greatest iemlib2 release (or in the CVS code; at least it doesn't crash here). promotion and you could also use zexy's [symbol2list] which provides similar functionality /promotion By the way, there doesn't seem to be a help file for splitfilename. there certainly is: http://pure-data.cvs.sourceforge.net/pure-data/externals/iemlib/iemlib2/splitfilename-help.pd nmfgasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small set of vector transforming abstractions
Roman Haefeli wrote: hi all during my trials with gem i made a little set of abstractions, that hopefully could be usefull when dealing with vectors. at least they have been for me. the set contains: [v_+] : adds two vectors [v_-] : subtracts a vector from another [v_scale] : scales a vector funnily enough theses have been part of Gem for a long time. they have been made abstractions and moved to markEx (along with other objects that are not directly related to Gem) [v_mag] : outputs the magnitude of a vector [v_normalize] : normalizes a vector (so that its magnitude becomes 1) [v_x] : computes the cross product of two vectors [v_rotate] : rotates a vector around another let me know if you miss something or if you find it not useable at all. why don't you just make them part of the frank's list-abstractions? mf.asdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small set of vector transforming abstractions
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: why don't you just make them part of the frank's list-abstractions? Because they already are? ;) But the versions of these in [list]-abs also handle arbitrary length lists and lists including symbols (which get ignored). If you already know, that you always have 3-element float lists you can optimize stuff a bit. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
i made some change to this abstraction in order to compute only the time use for the gemhead loop and not the time between 2 images. on my computer, it's about 11ms. but with the display list optimisation, it fall to 6ms about. cyrille Roman Haefeli a écrit : as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] wrote: i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. What? GEM doesn't use the DSP clock. It will take as much time as needed to render. oops. ok For example, the current work I have uses three or four 1080i clips, a live feed and records to disk and there is no way that all runs in 1.45ms. It takes about 12-15ms! anyway, i get dropouts when doing gem-rendering, although 'top' tells me that pd uses only 20% cpu-time. i don't care much about the audio (as IOhannes mentioned, i could run two instances of pd). the problem is that the timing is not nice. i'd like to run the patch with 20 frames per second. but in praxis each cycle needs 70ms, which gives me a framerate of 14. is my gpu too slow? what happens, when the gpu is overloaded? can that cause pd to stuck? i attached a little gem-benchmark-test. although you say, gem doesn't use the dsp-clock, it takes much longer to compute the first block after a gem-rendering command. why is that? and: here on my system, the [realtime] measures up to 70ms, when i go over [repeat 1400] (under 1400 it's 50ms). the funny thing is, that it stays around 70ms, even if i set the [repeat] up to 3000 or more. why is that? here on my system, cpu-time used by pd is always 20%. sorry to ask you so much.. but i try to understand things a bit better... roman ___ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 - check if it goes higher than 50ms; #X obj 217 298 cube 0.02; #X obj 217 211 translateXYZ -0.001 0 0; #X obj 217 263 translateXYZ 0 0 0.02; #X obj 31 249 bang~; #X obj 31 276 t b b; #X obj 31 300 realtime; #X obj 31 326 t b f; #X obj 31 350 f; #X obj 58 351 + 1; #X obj 31 379 pack f f; #X obj 99 245 gemhead; #X obj 99 270 b; #X obj 99 293 0; #X floatatom 31 434 0 0 0 0 - - -; #X floatatom 85 435 0 0 0 0 - - -; #X floatatom 127 435 0 0 0 0 - - -; #X floatatom 171 436 0 0 0 0 - - -; #X floatatom 214 436 0 0 0 0 - - -; #X floatatom 255 437 0 0 0 0 - - -; #X text 37 457 1; #X text 94 458 2; #X text 135 458 3; #X text 180 459 4; #X text 225 459 5; #X obj 31 403 route 0 1 2 3 4 5; #X text 262 459 6; #X text 28 477 realtime measured lenght of the nth dsp-cycle after the [gemhead] starts rendering.; #X obj 216 129 rotateXYZ 0 0 90; #X obj 216 187 repeat 2000; #X text 55 17 - rendering on/off; #X floatatom 380 146 5 0 0 0 - - -; #X text 425 143 - try different 'loads'; #X connect 1 0 2 0; #X connect 1 1 8 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 41 0; #X connect 5 0 42 0; #X connect 6 0 9 0; #X connect 8 0 0 0; #X connect 9 0 7 0; #X connect 10 0 11 0; #X connect 12 0 16 0; #X connect 15 0 12 0; #X connect 16 0 14 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 18 1 19 1; #X connect 19 0 20 0; #X connect 20 0 21 0; #X connect 20 1 23 1; #X connect 21 0 22 0; #X connect 21 0 23 0; #X connect 22 0 21 1; #X connect 23 0 38 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 26 0 21 1; #X connect 38 0 27 0; #X connect 38 1 28 0; #X connect 38 2 29 0; #X connect 38 3 30 0; #X connect 38 4 31 0; #X connect 38 5 32 0; #X
Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
hello cyrille thank you for the adjustments. i think i understand the difference between measuring the gemhead loop and the time between 2 images. but the other thing with the optimization still remains unclear to me and it seems, that it doesn't work here. when i stop the first and start the second gemhead, the gemwin becomes black. no primitives are drawn. there is no error in the pd-window (there is only a message '[GEMglNewList]: mode=4864' when i load the patch). does the optimization need some flags enabled when compiling gem? it seems, there is so much about gem, i don't know yet (like all these objects [GEMgl*] and [GLdefine] and the like, or the message 'FSAA 4'). to understand them, is it needed to know opengl well? are these objects documented somewhere in the Gem-documentation? i am not insulted if you don't have the time to answer all these questions... cheers roman On Thu, 2007-03-01 at 11:18 +0100, cyrille henry wrote: i made some change to this abstraction in order to compute only the time use for the gemhead loop and not the time between 2 images. on my computer, it's about 11ms. but with the display list optimisation, it fall to 6ms about. cyrille Roman Haefeli a écrit : as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] wrote: i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. What? GEM doesn't use the DSP clock. It will take as much time as needed to render. oops. ok For example, the current work I have uses three or four 1080i clips, a live feed and records to disk and there is no way that all runs in 1.45ms. It takes about 12-15ms! anyway, i get dropouts when doing gem-rendering, although 'top' tells me that pd uses only 20% cpu-time. i don't care much about the audio (as IOhannes mentioned, i could run two instances of pd). the problem is that the timing is not nice. i'd like to run the patch with 20 frames per second. but in praxis each cycle needs 70ms, which gives me a framerate of 14. is my gpu too slow? what happens, when the gpu is overloaded? can that cause pd to stuck? i attached a little gem-benchmark-test. although you say, gem doesn't use the dsp-clock, it takes much longer to compute the first block after a gem-rendering command. why is that? and: here on my system, the [realtime] measures up to 70ms, when i go over [repeat 1400] (under 1400 it's 50ms). the funny thing is, that it stays around 70ms, even if i set the [repeat] up to 3000 or more. why is that? here on my system, cpu-time used by pd is always 20%. sorry to ask you so much.. but i try to understand things a bit better... roman ___ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 - check if it goes higher than 50ms; #X obj 217 298 cube 0.02; #X obj 217 211 translateXYZ -0.001 0 0; #X obj 217 263 translateXYZ 0 0 0.02; #X obj 31 249 bang~; #X obj 31 276 t b b; #X obj 31 300 realtime; #X obj 31 326 t b f; #X obj 31 350 f; #X obj 58 351 + 1; #X obj 31 379 pack f f; #X obj 99 245 gemhead; #X obj 99 270 b; #X obj 99 293 0; #X floatatom 31 434 0 0 0 0 - - -; #X floatatom 85 435 0 0 0 0 - - -; #X floatatom 127 435 0 0 0 0 - - -; #X floatatom 171 436 0 0 0 0 - - -; #X floatatom
Re: [PD] GEM : fx to make persons appear only when they move
hi benjamin, sebastian trippner did exactly this in i seminar i gave. here is the description and patch to download: http://kunstundmedien.burg-halle.de/LEF/index.php?labor=erkenntniss=LEF he was using a very simple method: a snapshot (still image) from the video feed was placed over the video image as soon as the video showed no more movement. it's a very simple patch with not many onbjects. have fun with it. Am 01.03.2007 um 06:41 schrieb --: Hi list, I' trying to make an effect on a live camera feed with GEM for an installation in which only persons who move appear on a kind of video mirror, as chameleonTv of effecTv (http://effectv.sourceforge.net/chameleon.html) I tryed severals ways : with pix_background and pix_blob, modulating the alpha value of the rectangle on which the video is textured in function of the quantity of movement but if one person moves, everybody appears. with pix_multiblob and combination of pix_image pix_rectangle and pix_mask, the [pix_multiblob 2] seems to eat all the processor, even if I [pix_resize 320 240] the image before the multiblob. accumulating many (25) pix_movement and using the result by pix_masking it with the live feed dig a hole in the person that moves a little. Maybe I did not the average of alpha channel of the 25 previous frame as I thought, due to the fact that pix_movement works on the previous frame ? is there a better way with opengl instructions ? I tryed to look in that direction but I didn't manage yet to find how to analyze and affect the pixels of a live feed thanks for any advice benjamin for the tech note : the video feed is from a PCI capture card (AlchemyTv) connected in s-video to a dv camera with [pix_video 720 576] on a G5 10.4 Pd ext7, for the first trial, I manage to mix this video feed with another DV camera connected in firewire, putting into a buffer an image background, filling and playing another buffer with PAL images, and playing a non compressed video of the same size output on a second screen 800x600, with all that, the motion capture was really fast, only 40% of the proc used, it was really impressive (and stable), great dev work, thks -- ^ -[O:O]- ~ +--[¨]-- | | _/ \_ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
Roman Haefeli a écrit : hello cyrille thank you for the adjustments. i think i understand the difference between measuring the gemhead loop and the time between 2 images. but the other thing with the optimization still remains unclear to me and it seems, that it doesn't work here. when i stop the first and start the second gemhead, the gemwin becomes black. no primitives are drawn. there is no error in the pd-window (there is only a message '[GEMglNewList]: mode=4864' when i load the patch). does the optimization need some flags enabled when compiling gem? ous, sorry, it a bug in my patch. you just need to click on a bang : in the pd optimmized primitive windows : the top one. it should work if you click in this bang after starting the 2nd gemhead. it seems, there is so much about gem, i don't know yet (like all these objects [GEMgl*] and [GLdefine] and the like, or the message 'FSAA 4'). FSAA 4 is only here to enable antialiasing : the result is a much nice image if your hardware suport it. to understand them, is it needed to know opengl well? are these objects documented somewhere in the Gem-documentation? all GEMgl* object are direct wrapper for openGL fonctionnality. so a openGL book is the best documentation. the red book is well known to be the reference. but to be honest, it never try to understand how exaclty does the display list work in Gem, i just cut and paste. cyrille i am not insulted if you don't have the time to answer all these questions... cheers roman On Thu, 2007-03-01 at 11:18 +0100, cyrille henry wrote: i made some change to this abstraction in order to compute only the time use for the gemhead loop and not the time between 2 images. on my computer, it's about 11ms. but with the display list optimisation, it fall to 6ms about. cyrille Roman Haefeli a écrit : as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] wrote: i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. What? GEM doesn't use the DSP clock. It will take as much time as needed to render. oops. ok For example, the current work I have uses three or four 1080i clips, a live feed and records to disk and there is no way that all runs in 1.45ms. It takes about 12-15ms! anyway, i get dropouts when doing gem-rendering, although 'top' tells me that pd uses only 20% cpu-time. i don't care much about the audio (as IOhannes mentioned, i could run two instances of pd). the problem is that the timing is not nice. i'd like to run the patch with 20 frames per second. but in praxis each cycle needs 70ms, which gives me a framerate of 14. is my gpu too slow? what happens, when the gpu is overloaded? can that cause pd to stuck? i attached a little gem-benchmark-test. although you say, gem doesn't use the dsp-clock, it takes much longer to compute the first block after a gem-rendering command. why is that? and: here on my system, the [realtime] measures up to 70ms, when i go over [repeat 1400] (under 1400 it's 50ms). the funny thing is, that it stays around 70ms, even if i set the [repeat] up to 3000 or more. why is that? here on my system, cpu-time used by pd is always 20%. sorry to ask you so much.. but i try to understand things a bit better... roman ___ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 -
Re: [PD] a little pitchshifter
there's also G09.pitchshift.pd, which i've not looked at beyond simply triggering it. not fft but two playheads. drumloop timing is a bit messy and it looks different in construction than your patch (though i don't know what happens inside [susloop~]). i'm looking forward to getting on with miller's book and actually understand what this is all about... Thomas Mayer [EMAIL PROTECTED] wrote: The patch is just a little dirty hack with looping a 10 ms long sample (or cutting off a bit when pitching down). It would be better to do that with Fourier transformation, but I am too stupid^H^H^H^H^H^H^inexperienced to do that in Pd ;) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] re:Lindenmayer system in pd / GEM
Hi List.. I came across these patches by Cyrille Henry, the postings are from august 2006. when i try to open the patches i am missing rule and rule2. Strange that nobody mentioned it back then. Well i was just curious to see how its done in GEM. Best Regards Luigi See below, for an example -- #N canvas 561 190 503 642 10; #X obj 37 108 gemhead; #N canvas 0 0 558 408 + 0; #X obj 29 20 inlet; #X obj 28 69 translateXYZ 0 0 0; #X obj 29 46 rotateXYZ 0 0 30; #X obj 105 19 inlet; #X connect 0 0 2 0; #X connect 2 0 1 0; #X connect 3 0 2 3; #X restore 68 472 pd +; #N canvas 0 0 554 404 - 0; #X obj 29 20 inlet; #X obj 28 69 translateXYZ 0 0 0; #X obj 29 46 rotateXYZ 0 0 -30; #X obj 132 18 inlet; #X connect 0 0 2 0; #X connect 2 0 1 0; #X connect 3 0 2 3; #X restore 92 494 pd -; #X obj 37 351 any; #X obj 68 351 any; #X obj 92 351 any; #X obj 118 518 GEMglPushMatrix; #X obj 146 545 GEMglPopMatrix; #X obj 118 352 any; #X obj 146 352 any; #X floatatom 214 282 5 0 0 0 - - -; #X obj 37 156 rotateXYZ 0 0 90; #X floatatom 260 431 5 0 0 0 - - -; #X obj 231 363 line; #X floatatom 231 320 5 0 0 0 - - -; #X msg 231 340 \$1 100; #X floatatom 241 387 5 0 0 0 - - -; #X msg 231 300 0.2; #X obj 37 232 rule; #N canvas 189 124 601 813 F 0; #X obj 28 20 inlet; #X obj 284 140 inlet; #X obj 28 261 translateXYZ 0.05 0 0; #X obj 28 288 rotateXYZ; #X obj 337 143 inlet; #X obj 385 146 inlet; #X obj 28 189 rotateXYZ 0 90 0; #X obj 28 238 rotateXYZ 0 -90 0; #X obj 34 562 rotateXYZ; #X obj 28 93 t a b; #X obj 170 386 random 1000; #X obj 170 465 *; #X obj 248 387 random 1000; #X msg 170 361 seed \$1; #X obj 248 338 + 1; #X msg 248 362 seed \$1; #X obj 248 468 *; #X obj 78 385 random 1000; #X obj 78 331 r rand_seed; #X obj 117 430 r rand; #X obj 78 461 *; #X msg 78 357 seed \$1; #X obj 170 335 + 1; #X obj 78 410 - 500; #X obj 170 412 - 500; #X obj 248 412 - 500; #X obj 106 19 inlet; #X obj 106 48 unpack f f; #X text 175 46 size \, order; #X obj 116 73 - 1; #X obj 74 78 / 300; #X obj 114 128 / 300; #X obj 74 502 *; #X obj 165 505 *; #X obj 243 504 *; #X obj 317 440 + 1; #X obj 34 588 spigot; #X msg 190 572 1; #X msg 217 576 0; #X obj 34 612 color 0 1 0; #X obj 28 161 color 0.6 0.6 0.6; #X obj 34 635 scaleXYZ 1 0.33 0.1; #X obj 34 683 scaleXYZ 1 3 10; #X obj 34 659 sphere 0.05; #X obj 197 542 sel 1; #X obj 111 99 max 1; #X obj 28 214 tube 0.02 0.02 1 10; #X connect 0 0 9 0; #X connect 1 0 2 1; #X connect 1 0 46 3; #X connect 2 0 3 0; #X connect 3 0 8 0; #X connect 4 0 3 3; #X connect 5 0 3 1; #X connect 6 0 46 0; #X connect 7 0 2 0; #X connect 8 0 36 0; #X connect 9 0 40 0; #X connect 9 1 10 0; #X connect 9 1 17 0; #X connect 9 1 12 0; #X connect 10 0 24 0; #X connect 11 0 33 0; #X connect 12 0 25 0; #X connect 13 0 10 0; #X connect 14 0 15 0; #X connect 15 0 12 0; #X connect 16 0 34 0; #X connect 17 0 23 0; #X connect 18 0 21 0; #X connect 18 0 22 0; #X connect 19 0 20 1; #X connect 19 0 11 1; #X connect 19 0 16 1; #X connect 20 0 32 0; #X connect 21 0 17 0; #X connect 22 0 13 0; #X connect 22 0 14 0; #X connect 23 0 20 0; #X connect 24 0 11 0; #X connect 25 0 16 0; #X connect 26 0 27 0; #X connect 27 0 29 0; #X connect 27 0 30 0; #X connect 27 1 35 0; #X connect 27 1 44 0; #X connect 29 0 45 0; #X connect 30 0 46 1; #X connect 31 0 46 2; #X connect 32 0 8 1; #X connect 33 0 8 2; #X connect 34 0 8 3; #X connect 35 0 34 1; #X connect 35 0 33 1; #X connect 35 0 32 1; #X connect 36 0 39 0; #X connect 37 0 36 1; #X connect 38 0 36 1; #X connect 39 0 41 0; #X connect 40 0 6 0; #X connect 41 0 43 0; #X connect 43 0 42 0; #X connect 44 0 37 0; #X connect 44 1 38 0; #X connect 45 0 31 0; #X connect 46 0 7 0; #X restore 37 446 pd F -; #X obj 37 182 t b a b; #X obj 111 226 s rand_seed; #X obj 223 170 s rand; #X obj 223 148 / 1000; #X floatatom 223 130 5 0 0 0 - - -; #X floatatom 309 457 5 0 0 0 - - -; #X obj 37 298 route F + - [ ]; #X obj 68 323 t b; #X obj 92 323 t b; #X obj 118 323 t b; #X obj 146 324 t b; #X obj 37 323 t b l; #X msg 37 207 F 1 0; #X msg 260 409 30; #X msg 309 434 -30; #X obj 37 275 rule; #X obj 37 254 rule; #X msg 214 259 0.24; #X obj 37 133 translateXYZ 1 -3 0; #X msg 111 205 15; #X obj 38 11 gemhead; #X obj 38 33 world_light; #X msg 223 107 -34; #X obj 214 231 loadbang; #X obj 223 84 loadbang; #X obj 38 82 gemwin; #X msg 38 57 create \, 1 \, lighting 1; #X text 43 594 same exemple as the previus one \, but with some random.; #X text 42 616 you nead a good graphyc card to load that patch.; #X connect 0 0 38 0; #X connect 3 0 19 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X connect 8 0 6 0; #X connect 9 0 7 0; #X connect 10 0 19 2; #X connect 11 0 20 0; #X connect 12 0 1 1; #X connect 13 0 19 3; #X connect 14 0 15 0; #X connect 15 0 13 0; #X connect 16 0 19 4; #X connect 17 0 14 0; #X connect 18 0 36 0; #X connect 20 0 32 0; #X connect 20 1 3 1; #X connect 20 1 4 1; #X connect 20 1 5 1; #X connect
Re: [PD] small set of vector transforming abstractions
On Thu, 2007-03-01 at 10:53 +0100, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: why don't you just make them part of the frank's list-abstractions? Because they already are? ;) But the versions of these in [list]-abs also handle arbitrary length lists and lists including symbols (which get ignored). If you already know, that you always have 3-element float lists you can optimize stuff a bit. hey frank after a closer look to list-abs again, it turned out that almost all of the vector-abs are already implemented in list-abs and therefore could be considered obsolet. the only really new is [v_rotate] (it's _not_ the same as list-rot) and possibly [v_move], which is somehow related to [triple-scale]. however, i started with [v_rotate] which i was really missing and then one came after the other. i didn't meant to invent the wheel again. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small set of vector transforming abstractions
On Thu, 2007-03-01 at 10:10 +0100, IOhannes m zmoelnig wrote: Roman Haefeli wrote: hi all during my trials with gem i made a little set of abstractions, that hopefully could be usefull when dealing with vectors. at least they have been for me. the set contains: [v_+] : adds two vectors [v_-] : subtracts a vector from another [v_scale] : scales a vector funnily enough theses have been part of Gem for a long time. they have been made abstractions and moved to markEx (along with other objects that are not directly related to Gem) [v_mag] : outputs the magnitude of a vector [v_normalize] : normalizes a vector (so that its magnitude becomes 1) [v_x] : computes the cross product of two vectors [v_rotate] : rotates a vector around another let me know if you miss something or if you find it not useable at all. why don't you just make them part of the frank's list-abstractions? i don't think that these should get part of list-abs, though they share some functionality. the list-abs are so cool, because they work with any list with any length. the aim of the v_abs is really only dealing with vectors (list of 3 floatatoms) and they are a bit faster because of that. when passing 1000 vectors each gem render cycle, this could make a difference, i think. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small set of vector transforming abstractions
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: after a closer look to list-abs again, it turned out that almost all of the vector-abs are already implemented in list-abs and therefore could be considered obsolet. the only really new is [v_rotate] (it's _not_ the same as list-rot) and possibly [v_move], which is somehow related to [triple-scale]. however, i started with [v_rotate] which i was really missing and then one came after the other. i didn't meant to invent the wheel again. Not at all: I think, having a set of specific 3-element vector operations available as abstractions is very useful. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM : fx to make persons appear only when they move
Thanks Max for this example, in fact it is quite close to my first trial, it works fine but if there is 2 persons in the image, one move, the 2 persons appears and I would like to see only the person who is moving. I'll dig deeper... Benjamin Max Neupert a écrit : hi benjamin, sebastian trippner did exactly this in i seminar i gave. here is the description and patch to download: http://kunstundmedien.burg-halle.de/LEF/index.php?labor=erkenntniss=LEF he was using a very simple method: a snapshot (still image) from the video feed was placed over the video image as soon as the video showed no more movement. it's a very simple patch with not many onbjects. have fun with it. Am 01.03.2007 um 06:41 schrieb --: Hi list, I' trying to make an effect on a live camera feed with GEM for an installation in which only persons who move appear on a kind of video mirror, as chameleonTv of effecTv (http://effectv.sourceforge.net/chameleon.html) I tryed severals ways : with pix_background and pix_blob, modulating the alpha value of the rectangle on which the video is textured in function of the quantity of movement but if one person moves, everybody appears. with pix_multiblob and combination of pix_image pix_rectangle and pix_mask, the [pix_multiblob 2] seems to eat all the processor, even if I [pix_resize 320 240] the image before the multiblob. accumulating many (25) pix_movement and using the result by pix_masking it with the live feed dig a hole in the person that moves a little. Maybe I did not the average of alpha channel of the 25 previous frame as I thought, due to the fact that pix_movement works on the previous frame ? is there a better way with opengl instructions ? I tryed to look in that direction but I didn't manage yet to find how to analyze and affect the pixels of a live feed thanks for any advice benjamin for the tech note : the video feed is from a PCI capture card (AlchemyTv) connected in s-video to a dv camera with [pix_video 720 576] on a G5 10.4 Pd ext7, for the first trial, I manage to mix this video feed with another DV camera connected in firewire, putting into a buffer an image background, filling and playing another buffer with PAL images, and playing a non compressed video of the same size output on a second screen 800x600, with all that, the motion capture was really fast, only 40% of the proc used, it was really impressive (and stable), great dev work, thks -- ^ -[O:O]- ~ +--[¨]-- | | _/ \_ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ^ -[O:O]- ~ +--[¨]-- | | _/ \_ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd39.2 test 7 - text objects ++
Sure! My Pd time is pretty much weekend warrior status at this point, but I may make a project of trying to clean up some documentation/help patches. If I did this, what's the best way to get the change implemented? Also, what's the status of PDDP? ~Kyle On 2/28/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Complete, parsable documentation sounds good. Wanna help? :) .hc On Feb 27, 2007, at 9:38 AM, Kyle Klipowicz wrote: All of this confusion really enforces to me the importance of using separate external objects rather than libraries. Either that, or more complete, parseable documentation. ~Kyle On 2/27/07, cyrille henry [EMAIL PROTECTED] wrote: line3 is in nusmuk folder, it is not related to any lib. hope that help cyrille IOhannes m zmoelnig a écrit : timon wrote: Ive got cyclone zexy list-abs mapping iemlib hid activated. Same libs activated in the latest release but the below objects are now broken. Alternate - broken line3 - broken randomF - broken invert - broken this _might_ relate to markEx (even though the markEx objects are called [alternate] and [tripleLine]). obviously markEx is not loaded, so this might be your problem (markEx used to be part of Gem in the golden days, but is no longer) remote - broken ascseq - broken at least these objects are not in Gem/markEx, zexy, list-abs and iemlib. Which libs? I don't know the story on any of these. if you still have your old pd-extended version lying around (the one where these objects do work), you could start that one and open the help-patches for the borken objects. both the content of the help-patches and the full path of these might reveal which libraries they belong to. mfga.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Lindenmayer system in pd / GEM
Luigi Rensinghoff wrote: Hi List.. I came across these patches by Cyrille Henry, the postings are from august 2006. when i try to open the patches i am missing rule and rule2. Strange that nobody mentioned it back then. where did you get the patches from (exactly)? everywhere i have looked, the [rule] and [rule2] abstractions are included. mfa.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PDContainer complains about missing h_multiset_setup()
Hallo! I'm trying to install a new PDContainer, however while building goes fine, loading it makes Pd complain: thanks frank - this was a bug introduced because pdcontainer also compiles with the Pd-Extended buildsystem now! It is fixed in cvs ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Packing pointers into lists
Hi, it would be cool if the various operations of list-abs could also be made to work with pointers. However one important construct doesn't work and sometimes even lets Pd crash): extending a list with a pointer element using [list append]X[pointer] Attached patch illustrates what I mean: The example on the bottom right doesn't work correctly. I wonder: is this even supposed to work? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ pointer-pack-bug.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Google Summer of Code WIKI
Well, at least with OSX, there are Audio Units development kits available for free with their developers package (also free). I vaguely remember reading somewhere that Steinberg is cagey about VST API stuff, but am not sure. Something like this would really cause me to use Pd a whole lot more. Features that would be great are: -cross platform -ability to encapsulate a plug-in that has all libraries and abstractions included in a single file. -edit-ability in this encapsulated form I doubt that these things will be easy (if even possible to accomplish). Oh, and on the subject, maybe we could think about enlisting some 'summer help' on tcl/tk interface improvements as well? ~Kyle On 3/1/07, Josh Steiner [EMAIL PROTECTED] wrote: Georg Holzmann wrote: Hallo! Well, I guess updating PdVST is a little bit too small ... not if done correctly, it should be portable, support multiple plugin formats (ladsa, dx, vst), etc. would be a really good summer project. you are right ... but aren't there already hosts for all the plugins ? other way around, the project isnt to host plugins in pd, its to host pd patches as a plugins in other vst hosts (live, flstudio, whatever)... check out PdVST if you have a windows box... it works pretty well, but is based of a really outdated pd: http://www-crca.ucsd.edu/~jsarlo/pdvst/ i am unable... i removed PdVST from the short list, Pluggo4PD is probably a better descriptor, but now there is no little ? to click on. strange ;) ... I changed it to PluggoPD, now it's possible again ... it seems that for the wiki there should be no numbers in the names ... ahh, that makes some sense, thanks. i'll try to find some time soon to writeup a description. if anyone wants to pipe in with wanted features or maybe clues on how to implement this it would be helpful. -josh -- tasty electronic music vittles -- bluevitriol.com the only music blog you need-- playtherecords.com you are the dj. interactive music -- improbableorchestra.com random observations of the bizarre -- vitriolix.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Packing pointers into lists
Hi, See attached abstractions for a desperate (but working) way to store and recall lists of pointers ... Nevertheless, making this possible in a standard manner would be far more convincing ... Cheers Pierre Cage 2007/3/1, Frank Barknecht [EMAIL PROTECTED]: Hi, it would be cool if the various operations of list-abs could also be made to work with pointers. However one important construct doesn't work and sometimes even lets Pd crash): extending a list with a pointer element using [list append]X[pointer] Attached patch illustrates what I mean: The example on the bottom right doesn't work correctly. I wonder: is this even supposed to work? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list add-tag-pointer.pd Description: Binary data get-tag-pointer.pd Description: Binary data tag-pointer.pd Description: Binary data tag-pointers-help.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd joystick
Hi, I was looking for an external to receive data from a standard joystick (at least for windows). I only found the pd_joystick one that can be downloaded here: http://crca.ucsd.edu/~jsarlo/pd/ It works fine, but it has a huge design flaw in that the number of outlets depends on the number of axes of the joystick detected at startup. This makes it nearly useless in most serious patch development situations. I don't need to explain why, do I? Dose anyone know some better and more pd-minded alternative? Well, I guess pd-extended includes some, doesn'tit? however I would like to download just the joystick external rather than the whole pd-extended, so it would be fine to know how it's called etc. Thank you M. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] a little pitchshifter
on a related note, could someone answer a very basic question for me? what's the cheapest (in my effort and cpu effort) way to simply change the playback speed of some audio in an array? i.e. changing pitch and speed. at the moment i'm looping something with tabplay, but want to make a slider that adjusts the speed like a turntable. does it end up requiring fiddly interpolating or anything? thanks, pete. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] newbie growing pains...
On Feb 25, 2007, at 3:01 AM, carmen wrote: On Sun Feb 25, 2007 at 01:51:33AM -0500, Hans-Christoph Steiner wrote: On Feb 20, 2007, at 9:14 PM, Derek Holzer wrote: Hi Jared, for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-) Everybody has their own style, their own handwriting, and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe? Partially, I think this is due to lack of common practice in coding style and things like that. Most languages, programming or other, have a lot of standard practices when it comes to writing them done in different contexts. For whatever reason, the Pd/Max world has not developed many conventions, and I think that makes reading other people's patches harder. it couldnt possibly be beacuse the whole point or essence of a patch is often sphaghetti, or that theres no way to zoom out to see all the subpatches and abstractions on a single window.. Instead of zooming you can have subpatches of subpatches and abstractions that use abstractions. Then you can have a complecated system that fits on your screen. Some of my programs in Pd using 8 or more levels of abstraction. .hc .hc I learned PD by reproducing things which I understood already in stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc. First I played around with the built-in examples, then I made simple things and basic utilities. After that I went back to the examples I skipped and figured out what I did wrong, and then I moved on to porting things from other apps I had used before and knew the structure of (AudioMulch units, Reaktor instruments, various VSTs, etc). These kinds of exercises are the ones I think work best. Start from a point you know, and figure out how to do it with the most basic objects in PD. If core PD doesn't do it, then it's time to reach for an external. best, d. jared wrote: obvious similarities, but the more time I spend with PD the more they feel like different beasts. I will definitely go back and start from square one with PD. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 77: Give way to your worst impulse ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list - --- [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD Workshop files
On Feb 22, 2007, at 3:31 PM, Frank Barknecht wrote: Hallo, jared hat gesagt: // jared wrote: I downloaded the whole directory structure with wget ! Sorry, but what is wget? Where did you get it? Very nice workshop material - who made this ? Nicholas Ward Job Title:Part-time Lecturer (MScMM) Qualifications: M.A. Music Technology, M.Sc. Multimedia Systems e-mail: Nicholas dot Ward at cs.tcd.ie https://www.cs.tcd.ie/Nicholas.Ward/ Well, but the files included aren't all written by Nicholas Ward. This seems to be a collection of files and documents, that Nicholas found useful. But it includes stuff like the pmpd examples from CVS, the Gem-tutorial pdf by IOhannes etc. some files are by Derek Holzer, others by Aymeric Mansoux etc. But it's a nice selection. And Dave Sabine, and I would be very surprised if there wasn't a bit of Frank Barknecht in there ;). There is a bunch of workshop materials here, please add anything that is missing. : http://puredata.org/docs/workshops Also, I collected all the workshop materials I could find a year ago, then put them together into a collection, and added a bunch more. There is a lot of good stuff there, but it could use more work. It would be great to fold some of these into the existing collections. The idea is to break out into separate, standalone subtopics. These are included in the latests Pd-extended test versions under Help - Browser - manuals. There is 0.intro, '1.Sound', '2.Image', '3.Networking', and '4.Physical', in varying states of completion. Those are all meant to be the basic intros. It would be awesome to see topics like spectral gates, fm synthesis, build your own sampler, etc. etc. These are also in CVS in doc/tutorials: http://pure-data.cvs.sourceforge.net/pure-data/doc/tutorials .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
