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). and you could also use zexy's [symbol2list] which provides similar functionality > > 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
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; > >>
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=erkenntnis&s=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 smoo
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 conn
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=erkenntnis&s=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
Re: [PD] Lindenmayer system in pd / GEM
weird luigi was looking at these because i was just
looking at these two nights ago! I found them here:
http://lists.puredata.info/pipermail/pd-list/2004-09/022550.html
... and rule 1 and 2 are missing also for me. or maybe
im just dumb :)
cheers
mark
--- IOhannes m zmoelnig <[EMAIL PROTECTED]> wrote:
> 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
>
mark edward grimm | m.f.a | ed.m
megrimm.net | socialmediagroup.org & .com
[EMAIL PROTECTED] | 585.509.8703
__
___
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: > http://lists.puredata.info/pipermail/pd-list/2004-09/022550.html > > > This is the one. I chose that one, because like that: > >>#N canvas 0 0 445 503 10; >>#X obj 23 87 gemhead; >>#X obj 23 164 separator; >>#X obj 23 111 t a b; >>#X msg 120 152 seed 1; >>#X obj 23 328 translateXYZ; >>#X obj 23 353 circle 0.1; >>#X obj 23 57 gemwin; > > > with the reply ">"'s i was not able to get a running patch out of it. well, just strip the leading ">" with your favourite text editor ;-) anyhow, on the link given, there are several patches, all separated by the "-- next part --" unfortunately there are no hints as how each file should be called. luckily enought, frank posted them neatly zipped on: http://lists.puredata.info/pipermail/pd-list/2006-12/045052.html mfg.asdr IOhannes ___ 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
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
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] Google Summer of Code WIKI
hi all, > >>> 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've been changing some emails with stefano d'angelo, who is starting to write a plugin wrapper, which is supposed to work with different plugin backends (vst, ladspa ...) ... a pluggo for pd could make use of this project in order to support several platforms out of the box. i guess, stefano doesn't have a working prototype, yet, but it's probably a good idea to join the development resources in order do avoid duplicate work. his project website is http://sourceforge.net/projects/naspro/ in general, from my knowledge of the pd architecture, running pd in a plugin environment would require some non-trival changes, it can't be just implemented on top of the current implementation. which means, in some way, this has to be incorporated into vanilla pd ... so imo, such a project should be coordinated with miller in order to avoid that the effort is wasted, just because he doesn't incorporate the changes. tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Every word is like an unnecessary stain on silence and nothingness Samuel Beckett signature.asc Description: This is a digitally signed message part ___ 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] is this a spectral gate?
That is very nice. We need more stuff like this! Unfortunately, the sound breaks up badly when I draw in the arrays. Does that happen on other platforms? I am on Mac OS X. I wonder if there is a more efficient way to do the drawing part. I added a little splash of color and some simple step-by-step instructions for the newbies. Stuff like this is the perfect way to inspire people to learn Pd. specdelay~-help.pd Description: Binary data .hc On Feb 23, 2007, at 1:10 PM, Josh Steiner wrote: that is one hell of a lot of fun to play with. padawan12 wrote: On Wed, 21 Feb 2007 10:30:28 +0100 Frank Barknecht <[EMAIL PROTECTED]> wrote: A couple of little improvements to specdelay to make it more useful as an audio effect. Hallo, David Powers hat gesagt: // David Powers wrote: I wish there was an "fft for dumbies" ... or, I guess, some kind of fft "black boxes" to play with, where you don't need to understand the math. Frank's recent post completely lost me, Now I'm disappointed ... though given a bit of study I can probably decode it. ... ah, and relieved a bit again. ;) But, for instance, in Reaktor or Plogue Bidule, you can move stuff into fft, mess with it, and resynthesize, without having any idea what the hell the math is. In comparison, I really couldn't understand the PD fft examples at all, it's just been too many years since I had a math class. The power of Pd of course is, that you can influence things on a much lower level than NI allows you to do in Reaktor - although I admit, that I only know Reaktor from screenshots. The downside is, that you have to dig deeper to make the most out of Pd. This is especially true for FFT applications. The actual FFT patches often are very simple and they contain just of a handful of objects. It's the knowledge hidden inside that makes them difficult to understand. While you can skip a lot of the math, you cannot do FFT in Pd without at least understanding what kind of data is generated by the two [rfft~] outlets. Because without understanding this, you cannot even "fool around" with the data in between [rfft~] and [rifft~] in a meaningful way. Anyway, to give you a blackbox maybe like in Reaktor, attached is a Spectral Delay GOP abstraction ready to be dropped into any glitch patch. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ 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 All information should be free. - the hacker ethic ___ 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
Re: [PD] State Saving - Summary
On Feb 14, 2007, at 10:17 AM, Frank Barknecht wrote: > Hallo, > Roman Haefeli hat gesagt: // Roman Haefeli wrote: > >> the state saving is more a side effect, since the main goal was to >> provide a system, that makes sure, that all patches have the same >> state, >> no matter when a user joins a running session. since that was >> implemented, it was very easy to use the same system to write states >> into files and store them again. > > Yep, that's what a state saving system should have in mind anyways: > state saving should not be tied to files alone, it should also allow > saving "to the net" or to CVS etc. I think, this is done very nicely > in netpd. > > >> the netpd-framework only provides >> functionality to save states of single patches. if you want to >> save the >> state of all opened patches, you would need to write your own >> preset-manager (which is not that difficult and there are already >> examples). >> anyway, the netpd-state saving system is made for netpd and does only >> work for netpd. > > Really? I didn't have a deep look at it yet but I was under the > impression that the actual state collectors are very similar > to sssad and thus should be easy to make just as flexible in regard to > "frameworks". > > One thing that is on my TODO list for [sssad] is local saving, that > is, reading and writing only the state of the current $0-namespace. > There already is quite a clear image of how to implement this in my > mind, I'll just need to sit down and patch and test it. How about a wiki page? puredata.org/docs/ seems like a good place for the page. .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 ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] a little pitchshifter
On Wed, 2007-02-28 at 23:00 +0100, Thomas Mayer wrote: > robbert van hulzen wrote: > > well then, thanks for doing my homework! ;) > > nice one. (i like how it gives a kind of flanger effect on the drum loop i > > tried it with, almost more like a filter, because of the high noise portion > > of the signal, i suppose.) > > cheers, robbert > > 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 ;) hi thomas i posted once an fft-based pitchshifter, which is based on millers I07.phase.vocoder.pd . you can get it here: http://lists.puredata.info/pipermail/pd-list/2006-03/036241.html be aware, that it is quite cpu-hungry. roman ___ Der frühe Vogel fängt 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
Re: [PD] is this a spectral gate?
Yeah - I agree. This would be a nice addition to the pd examples since it uses all standard objects, or maybe there could be a package that includes things like this. I started learning Pd in May of last year and I always thought the audio examples were fine; effective but a little dry. Something like this would allow people to have a lot more fun from the get-go! It's things like this, or Derek's particlechamber (too bad it needs grid) that would be great especially for people coming from other softwares or the electronic music scene, just to demonstrate that these kind of things are happening in pd right off the bat :) Might be a nice little bit of encouragement. I don't have any problems with drawing the arrays on an iMac g5 10.4. Kevin On 3/1/07, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > That is very nice. We need more stuff like this! > > Unfortunately, the sound breaks up badly when I draw in the arrays. > Does that happen on other platforms? I am on Mac OS X. I wonder if > there is a more efficient way to do the drawing part. > > I added a little splash of color and some simple step-by-step > instructions for the newbies. Stuff like this is the perfect way to > inspire people to learn Pd. > > > > .hc > > On Feb 23, 2007, at 1:10 PM, Josh Steiner wrote: > > > that is one hell of a lot of fun to play with. > > > > > > padawan12 wrote: > >> On Wed, 21 Feb 2007 10:30:28 +0100 > >> Frank Barknecht <[EMAIL PROTECTED]> wrote: > >> > >> > >> A couple of little improvements to specdelay to make it more > >> useful as an > >> audio effect. > >> > >> > >>> Hallo, > >>> David Powers hat gesagt: // David Powers wrote: > >>> > >>> > I wish there was an "fft for dumbies" ... or, I guess, some kind of > fft "black boxes" to play with, where you don't need to > understand the > math. Frank's recent post completely lost me, > > >>> Now I'm disappointed ... > >>> > >>> > though given a bit of study I can probably decode it. > > >>> ... ah, and relieved a bit again. ;) > >>> > >>> > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > into fft, mess with it, and resynthesize, without having any > idea what > the hell the math is. In comparison, I really couldn't > understand the > PD fft examples at all, it's just been too many years since I had a > math class. > > >>> The power of Pd of course is, that you can influence things on a > >>> much > >>> lower level than NI allows you to do in Reaktor - although I admit, > >>> that I only know Reaktor from screenshots. The downside is, that you > >>> have to dig deeper to make the most out of Pd. This is especially > >>> true > >>> for FFT applications. The actual FFT patches often are very > >>> simple and > >>> they contain just of a handful of objects. It's the knowledge hidden > >>> inside that makes them difficult to understand. > >>> > >>> While you can skip a lot of the math, you cannot do FFT in Pd > >>> without > >>> at least understanding what kind of data is generated by the two > >>> [rfft~] outlets. Because without understanding this, you cannot even > >>> "fool around" with the data in between [rfft~] and [rifft~] in a > >>> meaningful way. > >>> > >>> Anyway, to give you a blackbox maybe like in Reaktor, attached is a > >>> Spectral Delay GOP abstraction ready to be dropped into any glitch > >>> patch. > >>> > >>> Ciao > >>> -- > >>> Frank Barknecht _ __footils.org_ __goto10.org__ > >>> > >>> > >>> > >>> > >>> > >>> ___ > >>> 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 > > > > > > All information should be free. - the hacker ethic > > > > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > -- http://pocketkm.blogspot.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Google Summer of Code WIKI
On Thu, Mar 01, 2007 at 11:46:50AM -0800, Josh Steiner wrote: > 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/ It also works perfectly under Wine, for those of us in the minority (of one?) running GPL Windows trackers with VST support, on Linux using Wine. :) God I love Free Software. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] a little pitchshifter
peter, use this construction: [phasor~] | | [r arraylength] | | [*~ ] | [tabread4~ arrayname] where, "arraylength" is the value obtained from the outlet of [soundfiler] when you load your sample. the speed of the phasor should be set at ( 44100 / arraylength ) to play at a normal pitch (assuming your samplerate is 44100hz)..and multiplying or dividing this value by a scalar you can change the pplayback speed ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Packing pointers into lists
Hallo, pierre cage hat gesagt: // pierre cage wrote: > 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 ... Very nice package. I think, I was using a similar approach in my xy-controller to speed up pointer access, but having the idiom in a set of readymade 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
