[PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
hello cyrille thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed. putting this in the render chain works and gives the expected result: [t b b a] | // [any ] but this makes pd/gem completely stuck: [t b b a] | | | | [del 10] | | // [any ] as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution. 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. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done. how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize? roman On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote: to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash. cyrille Roman Haefeli a écrit : hi all it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers). i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied). is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer? any help appreciated! 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ 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
[PD] PDContainer complains about missing h_multiset_setup()
Hi, I'm trying to install a new PDContainer, however while building goes fine, loading it makes Pd complain: /usr/lib/pd/externs/PDContainer.pd_linux: /usr/lib/pd/externs/PDContainer.pd_linux: undefined symbol : _Z16h_multiset_setupv This symbol is: $ c++filt _Z16h_multiset_setupv h_multiset_setup() Any ideas? The source looks okay to my eyes. This is on Debian testing using g++ (GCC) 4.0.3. $ ldd /usr/lib/pd/externs/PDContainer.pd_linux linux-gate.so.1 = (0xe000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb7dc5000) libm.so.6 = /lib/tls/libm.so.6 (0xb7da) libc.so.6 = /lib/tls/libc.so.6 (0xb7c6e000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb7c63000) /lib/ld-linux.so.2 (0x8000) 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] PDContainer complains about missing h_multiset_setup()
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Any ideas? The source looks okay to my eyes. This is on Debian testing using g++ (GCC) 4.0.3. It's the same with this: g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) 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] PDContainer complains about missing h_multiset_setup()
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Frank Barknecht hat gesagt: // Frank Barknecht wrote: Any ideas? The source looks okay to my eyes. More info: This doesn't seem to be related to just multiset. If I uncomment the multiset code, the setup for h_set is not found, and if I remove that as well, the same happens with other setup-functions. 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] Tower of Hanoi
Hey list, I've toyed with an implementation of a solution to the Tower of Hanoi problem in Pd. It ended up being too simple once i skipped trying to use the recursive algorithm that normally is used to solve the problem. Instead i've used an iterative algorithm that uses a binary representation of each move, and from that the disk number being moved, from where it's moved and where to, is fairly simply calculations using the bitwise operators that ships with Pd ( - which I thought i was gonna implement that first, but no). See for example the wikipedia entry on the topic for more info. Attached is the patch, made as an abstraction, and a help file that demonstrate it. Any comment is very welcome! Best, Steffen hanoi.pd Description: Binary data hanoi-help.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tower of Hanoi
will have a look now, but wikipedia says it takes 561 billion years to get a solution. you may never see me again! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] retrieving DIO errors from within a patch
Hi list, I wonder whether it is possible to retrieve information about DIO errors (specifically, AD/DA sync errors) from within a patch? If so, can this be made in one and the same way for different OSs? Thanks for suggestions, Matthias ___ 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 (?)
Frank Barknecht a écrit : Hallo, cyrille henry hat gesagt: // cyrille henry wrote: don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in : repeat 1000 [ GEMglCallList I've never hear of this optimization, do you have an example for it? here is an exemple that iohannes send to the list time ago. it should be use like a normal primitive. cyrille Ciao #N canvas 232 98 791 542 10; #X obj 37 279 inlet gemlist; #X obj 37 384 outlet gemlist; #X obj 419 180 inlet size; #X obj 505 180 inlet slice; #N canvas 0 0 450 300 closedcylinder 0; #X obj 37 9 inlet gemlist; #X obj 301 73 loadbang; #X obj 37 112 cylinder; #X obj 290 30 inlet size; #X obj 376 30 inlet slice; #X obj 261 118 f \$1; #X obj 347 119 f \$2; #X obj 301 92 t b b; #X obj 135 93 t f f f; #X obj 110 118 t f f f; #X obj 168 118 t f f; #X obj 37 246 disk 1; #X obj 37 199 disk 1; #X obj 185 72 t f f; #X obj 152 47 t f f; #X obj 37 173 translate 1 0 0 1; #X obj 37 223 translate 1 0 0 -2; #X obj 261 141 t f f; #X obj 261 161 0; #X obj 261 181 select 1; #X obj 261 200 f; #X obj 347 141 t f f; #X obj 347 161 0; #X obj 347 181 select 1; #X obj 347 200 f; #X connect 0 0 2 0; #X connect 1 0 7 0; #X connect 2 0 15 0; #X connect 3 0 20 0; #X connect 4 0 24 0; #X connect 5 0 17 0; #X connect 6 0 21 0; #X connect 7 0 5 0; #X connect 7 1 6 0; #X connect 8 0 2 1; #X connect 8 1 9 0; #X connect 8 2 10 0; #X connect 9 0 15 1; #X connect 9 1 16 1; #X connect 10 0 12 1; #X connect 10 1 11 1; #X connect 12 0 16 0; #X connect 13 0 12 2; #X connect 13 1 11 2; #X connect 14 0 2 2; #X connect 14 1 13 0; #X connect 15 0 12 0; #X connect 16 0 11 0; #X connect 17 0 18 0; #X connect 17 1 20 1; #X connect 18 0 19 0; #X connect 19 0 20 0; #X connect 20 0 8 0; #X connect 21 0 22 0; #X connect 21 1 24 1; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 14 0; #X restore 186 467 pd closedcylinder; #X obj 186 221 GEMglGenLists 1; #X obj 156 398 GEMglNewList; #X obj 37 322 GEMglCallList; #N canvas 0 0 450 300 once 0; #X obj 91 62 inlet; #X obj 91 266 outlet; #X obj 91 150 spigot 1; #X obj 91 175 t a b; #X msg 121 197 0; #X obj 298 57 inlet open; #X obj 298 92 t b; #X msg 142 128 1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 2 1; #X restore 186 199 pd once; #N canvas 0 0 450 300 once 0; #X obj 91 62 inlet; #X obj 91 266 outlet; #X obj 91 150 spigot 1; #X obj 91 175 t a b; #X msg 121 197 0; #X obj 298 57 inlet open; #X obj 298 92 t b; #X msg 142 128 1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 2 1; #X restore 156 372 pd once; #X obj 419 201 t b f; #X obj 505 202 t b f; #X obj 235 354 loadbang; #X obj 235 373 GLdefine GL_COMPILE; #X msg 230 178 bang; #X obj 156 488 GEMglEndList; #X obj 156 425 t a a; #X obj 186 446 separator; #X obj 156 113 gemhead 1; #X obj 316 267 t b; #X obj 156 138 t a a; #X obj 286 241 t f b; #X obj 165 268 t f f; #X msg 305 343 bang; #N canvas 0 0 450 300 closedcylinder 0; #X obj 37 9 inlet gemlist; #X obj 37 274 outlet gemlist; #X obj 301 73 loadbang; #X obj 37 112 cylinder; #X obj 290 30 inlet size; #X obj 376 30 inlet slice; #X obj 261 118 f \$1; #X obj 347 119 f \$2; #X obj 301 92 t b b; #X obj 135 93 t f f f; #X obj 110 118 t f f f; #X obj 168 118 t f f; #X obj 67 246 disk 1; #X obj 67 199 disk 1; #X obj 185 72 t f f; #X obj 152 47 t f f; #X obj 37 131 t a a; #X obj 67 151 separator; #X obj 67 173 translate 1 0 0 1; #X obj 67 223 translate 1 0 0 -2; #X obj 261 141 t f f; #X obj 261 161 0; #X obj 261 181 select 1; #X obj 261 200 f; #X obj 347 141 t f f; #X obj 347 161 0; #X obj 347 181 select 1; #X obj 347 200 f; #X connect 0 0 3 0; #X connect 2 0 8 0; #X connect 3 0 16 0; #X connect 4 0 23 0; #X connect 5 0 27 0; #X connect 6 0 20 0; #X connect 7 0 24 0; #X connect 8 0 6 0; #X connect 8 1 7 0; #X connect 9 0 3 1; #X connect 9 1 10 0; #X connect 9 2 11 0; #X connect 10 0 18 1; #X connect 10 1 19 1; #X connect 11 0 13 1; #X connect 11 1 12 1; #X connect 13 0 19 0; #X connect 14 0 13 2; #X connect 14 1 12 2; #X connect 15 0 3 2; #X connect 15 1 14 0; #X connect 16 0 1 0; #X connect 16 1 17 0; #X connect 17 0 18 0; #X connect 18 0 13 0; #X connect 19 0 12 0; #X connect 20 0 21 0; #X connect 20 1 23 1; #X connect 21 0 22 0; #X connect 22 0 23 0; #X connect 23 0 9 0; #X connect 24 0 25 0; #X connect 24 1 27 1; #X connect 25 0 26 0; #X connect 26 0 27 0; #X connect 27 0 15 0; #X restore 469 494 pd closedcylinder; #X text 346 477 this is a version without the openGL-wrapper; #X text 360 491 it is slower::; #X text 48 21 this is an example of how to use Gem's openGL-wrapper-objects to speed up things; #X connect 0 0 7 0; #X connect 2 0 10 0; #X connect 3 0 11 0; #X connect 5 1 21 0; #X connect 6 0 16 0; #X connect 7 0 1 0; #X
Re: [PD] spread Gem-computation over several dsp-cycles (?)
cyrille henry a écrit : hello, anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card. btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). patch to make this is almost the LS demo patch i send to this list few time ago. ok, i don't make sound with those, but a good graphic card really improve processing speed. cyrille don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in : repeat 1000 [ GEMglCallList cyrille Roman Haefeli a écrit : hello cyrille thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed. putting this in the render chain works and gives the expected result: [t b b a] | // [any ] but this makes pd/gem completely stuck: [t b b a] | | | | [del 10] | | // [any ] as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution. 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. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done. how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize? roman On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote: to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash. cyrille Roman Haefeli a écrit : hi all it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers). i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied). is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer? any help appreciated! 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ 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 ___ 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
[PD] strange behavior of splitfilename
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? By the way, there doesn't seem to be a help file for splitfilename. Thanks, Matthias #N canvas 0 0 288 305 10; #X obj 63 138 savepanel; #X obj 63 111 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 63 171 splitfilename .; #X obj 63 199 print; #X obj 163 199 print; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 2 1 4 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] a little pitchshifter
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 ;) cu Thomas -- Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance. (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.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 (?)
hi IOhannes On Wed, 2007-02-28 at 14:46 +0100, IOhannes m zmoelnig wrote: Roman Haefeli wrote: hello cyrille thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed. putting this in the render chain works and gives the expected result: [t b b a] | // [any ] but this makes pd/gem completely stuck: [t b b a] | | | | [del 10] | | // [any ] as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution. this is not a question of the design of Gem but of openGL. for most objects (but the pix_ stuff), Gem directly communicates with the underlying openGL-infrastructure. for this to work, one must get hold of the openGL context. using delayed gem-messages, the openGL-context will most likely be grabbed by another application. 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. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done. on the long run i have plans to put the rendering into a separate thread. however, don't expect it too soon. hm... i am bit unsure now. chris clepper said in his previous mail, that gem rendering is not bound to the dsp-ticks. but when you say, that threading would help in this case, does that mean, the rendering _is_ bound to the dsp-ticks? do i understand something wrong? how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize? 2 ways: - use longer audio buffers (e.g. 100ms) for some reason, it doesn't help here. it's not the audio i care about, but that timing is lost and the desired frameperiod grows to 70ms. and what is most surprising here, sometimes i close the patch i am working on and open it again and start rendering and for some unexplainable reason: frameperiod is 50ms. this is with the same patch with the same gem-objects in gemwin. - use 2 instances of pd: one for audio and one for video; one of them (or a third one) is master and controls the rest. yeah, when i want to do audio at the same time, i'll do that. 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] spread Gem-computation over several dsp-cycles (?)
On Wed, 2007-02-28 at 17:15 +0100, cyrille henry wrote: btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). hey, soo nice pictures. do you have also a movie of them? wonderfull to see what is possible with gem. roman patch to make this is almost the LS demo patch i send to this list few time ago. ok, i don't make sound with those, but a good graphic card really improve processing speed. cyrille ___ 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] Tower of Hanoi
On 28/02/2007, at 13.32, hard off wrote: will have a look now, but wikipedia says it takes 561 billion years to get a solution. you may never see me again! Yes, if you set it up with 64 disks and 1 sec. delay between each move... Hope you come back. Best, Steffen ___ 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 (?)
Roman Haefeli a écrit : On Wed, 2007-02-28 at 17:15 +0100, cyrille henry wrote: btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). hey, soo nice pictures. do you have also a movie of them? no, they did not really move. thanks c wonderfull to see what is possible with gem. roman patch to make this is almost the LS demo patch i send to this list few time ago. ok, i don't make sound with those, but a good graphic card really improve processing speed. cyrille ___ 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] small set of vector transforming abstractions
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 [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. it can be downloaded from here: http://romanhaefeli.net/pd/v_abstractions.tar.gz 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] spread Gem-computation over several dsp-cycles (?)
On Wed, Feb 28, 2007 at 05:15:32PM +0100, cyrille henry wrote: anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card. btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). Awesome!!! 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] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
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 connect 41 0 5 0; #X connect 42 0 15 0; #X connect 44 0 42 1; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Gem] angles - vector translation
patrick a écrit : i agree! i tried the patch for multiple points of views (camera). it's really neat! but would it be possible to translate (moving) the camera position from point 1 to point 2. maybe with an ease-in / out or elastic effect (using msd or pmpd?!?). pat Hans-Christoph Steiner a écrit : It would be very nice to have these bundled up into a reusable library. I think the view changing with the mouse should be a standard setup when working with Gem. .hc ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Hello, you can still put a [line] for switching smoothly from a view to another, like in attached patch, or put the tgrill smoother instead of [line]: [inlet] | [sig~][r $0-smoothing] | | [lop~ 0.8] | | [metro 15] | / [snapshot~] | [outlet] patco #N canvas 469 151 478 458 10; #X msg 162 86 destroy; #X obj 150 126 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 306 308 gemhead; #X obj 11 222 gemhead; #X obj 306 341 cube 0.5; #X obj 11 298 cube 0.4; #N canvas -46 0 1020 696 position 0; #X obj 87 668 outlet; #X obj 302 234 f; #X obj 219 217 spigot; #X obj 280 208 sel 0 1; #X obj 250 189 t f f; #X obj 176 229 f; #X obj 87 205 spigot; #X obj 154 205 sel 0 1; #X obj 130 179 t f f; #X obj 423 227 f; #X obj 340 211 spigot; #X obj 401 202 sel 0 1; #X obj 371 183 t f f; #X obj 340 363 t b f; #X obj 101 436 cos; #X obj 113 494 * 1; #X obj 87 494 * 1; #X obj 145 438 sin; #X obj 101 458 t b f; #X obj 87 372 sin; #X obj 113 373 cos; #X msg 264 525 1; #X obj 264 477 0; #X obj 264 499 sel 1 0; #X msg 296 526 -1; #X obj 87 141 t f f; #X obj 87 249 -; #X obj 219 256 -; #X obj 340 262 -; #X obj 87 305 * -3.14; #X obj 149 376 * 3.14; #X obj 88 35 gemmouse 0.5 1; #X obj 87 279 + -0.25; #X obj 340 311 + 2; #X obj 340 335 * 10; #X obj 154 257 -0.25; #X obj 401 272 2; #X obj 219 279 + 0.25; #X obj 280 278 0.25; #X obj 87 529 * 20; #X obj 114 530 * 20; #X obj 148 532 * 20; #X obj 340 387 t b b b; #X obj 110 92 t f f f f; #X obj 87 327 t f f; #X obj 149 398 t f f; #X msg 87 644 view \$1 \$2 \$3 \$4 \$5 \$6 0 \$7 0; #X obj 381 411 r \$0-target; #X obj 379 460 list trim; #X obj 381 483 unpack f f f; #X obj 362 539 line; #X obj 363 513 pack f 500; #X obj 428 538 line; #X obj 429 515 pack f 500; #X obj 493 537 line; #X obj 494 514 pack f 500; #X obj 507 465 r \$0-targetf; #X obj 361 560 t b a; #X obj 426 559 t b a; #X obj 490 558 t b a; #X obj 100 620 pack 10 14 10 0 0 0 1; #X connect 1 0 27 1; #X connect 2 0 27 0; #X connect 3 0 38 0; #X connect 3 1 1 0; #X connect 4 0 2 1; #X connect 4 1 3 0; #X connect 5 0 26 1; #X connect 6 0 26 0; #X connect 7 0 35 0; #X connect 7 1 5 0; #X connect 8 0 6 1; #X connect 8 1 7 0; #X connect 9 0 28 1; #X connect 10 0 28 0; #X connect 11 0 36 0; #X connect 11 1 9 0; #X connect 12 0 10 1; #X connect 12 1 11 0; #X connect 13 0 42 0; #X connect 13 1 39 1; #X connect 13 1 40 1; #X connect 13 1 41 1; #X connect 14 0 18 0; #X connect 14 0 22 0; #X connect 15 0 41 0; #X connect 16 0 39 0; #X connect 17 0 40 0; #X connect 18 0 15 0; #X connect 18 0 16 0; #X connect 18 1 15 1; #X connect 18 1 16 1; #X connect 19 0 16 0; #X connect 20 0 15 0; #X connect 21 0 60 6; #X connect 22 0 23 0; #X connect 23 0 21 0; #X connect 23 1 24 0; #X connect 24 0 60 6; #X connect 25 0 6 0; #X connect 25 1 5 1; #X connect 26 0 32 0; #X connect 27 0 37 0; #X connect 28 0 33 0; #X connect 29 0 44 0; #X connect 30 0 45 0; #X connect 31 0 25 0; #X connect 31 1 43 0; #X connect 31 2 4 0; #X connect 31 2 8 0; #X connect 31 3 12 0; #X connect 31 4 12 0; #X connect 32 0 29 0; #X connect 32 0 35 1; #X connect 33 0 34 0; #X connect 33 0 36 1; #X connect 34 0 13 0; #X connect 35 0 32 1; #X connect 36 0 33 1; #X connect 37 0 30 0; #X connect 37 0 38 1; #X connect 38 0 37 1; #X connect 39 0 60 0; #X connect 40 0 60 1; #X connect 41 0 60 2; #X connect 42 0 39 0; #X connect 42 1 40 0; #X connect 42 2 41 0; #X connect 43 0 2 0; #X connect 43 1 1 1; #X connect 43 2 10 0; #X connect 43 3 9 1; #X connect 44 0 19 0; #X connect 44 1 20 0; #X connect 45 0 14 0; #X connect 45 1 17 0; #X connect 46 0 0 0; #X connect 47 0 48 0; #X connect 48 0 49 0; #X connect 49 0 51 0; #X connect 49 1 53 0; #X connect 49 2 55 0; #X connect 50 0 57 0; #X connect 51 0 50 0; #X connect 52 0 58 0; #X connect 53 0 52 0; #X connect 54 0 59 0; #X connect 55 0 54 0; #X connect 56 0 51 1; #X connect 56 0 53 1; #X connect 56 0 55 1; #X connect 57 0 60 0; #X connect 57 1 60 3; #X connect 58 0 60 0; #X connect 58 1 60 4; #X connect 59 0 60 0; #X connect 59 1 60 5; #X connect 60 0 46 0; #X restore 101 24 pd position; #X msg 142 60 create \, 1; #X obj 97 392 s \$0-target; #X obj 376 341 s \$0-target; #X msg 370 296 0 0 0; #X obj 11 262 translateXYZ 5 0 0; #X obj 126 319 pack 5 0 0; #N canvas 525 14 470 320 togone 0; #X obj 102 103 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 101 28 sel
Re: [PD] [PD-announce] KnobsAndSlidersDS
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. And then I didn't really figure out how the knobs should be used. I They work by pressing down and then moving left or right. I guess I should make this more intuitive. Do you have any suggestions? Ah, I thought, movement was either radial or up/down. I didn't even try left/right. It would be interesting to test radial movement. On a computer screen this is horrible of course, but it may work on a touchscreen, see above. Radial movement could be pretty neat. I can put in up/down quite easily, but radial would be a bit more complex (but I will probably try it eventually). Another widget idea: Multisliders or [table] would be cool. That would be cool! I also think a number box would be great, and a general 'button' like a bang in Pd, and text/comments of some kind. My progress implementing these will probably be quite slow, but I need all these things before the end of the year, so I'll try to release early, release often. 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] pd39.2 test 7 - text objects ++
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fn delete
AFAIK, all key mapping is done in pd.tk (aka u_main.tk). But that doesn't mean that it's simple to track down. That's part of what need fixing ;). Look for all the bind statements in pd.tk. Part of the problem is that Pd turns off a lot of the default Tcl/Tk bindings, which is probably the cause behind the problem that started this thread. .hc On Feb 28, 2007, at 4:01 AM, Luke Iannini (pd) wrote: I had a look with no prior knowledge of Tcl/Tk... I have no idea where the Delete message is being intercepted. It is not in pd.tk, afaict; it looks like it is being caught and told to send keycode 8 (backspace). I was able to change BackSpace's keycode successfully (e.g. to a . character) but changes to the Delete keycode still show up as the box. Strangely, the Delete keysym shows up in the console if you uncomment the debug code at the top of the proc, so I'm not sure where this is getting messed up (I found no other references in pd.tk). So, hope that confuses someone. Does anyone know if windows can be set to fill while resizing in Tcl/Tk? I've had a look around and can't find anything, and all other Tk apps I've tried in OS X have the same transparent frame/Windows 95/OS 9 style resize, so I assume that is a no. Yeah, the key mappings are a mess in Pd. It's all handled in Tcl. This needs a clean-up on all platforms. Anyone want to try? .hc On Feb 27, 2007, at 2:25 PM, marius schebella wrote: Hi, speaking about annoying things so much leads me to post another problem, that fn + delete, which usually deletes the character right of the cursor on osx, does not work in pd. there appears a funny rectangle character. maybe this one is easier to solve? I also had that problem on some linux machines, btw. whereas on windows it was not possible at all to delete what is right of the cursor, if I remember correctly. marius. ___ 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 ___ 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
[PD] GEM : fx to make persons appear only when they move
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
Re: [PD] small set of vector transforming abstractions
How convenient to be having linear algebra AND complex math in the same week! (Now for how they are related...) More like this, please!!! ~Kyle On 2/28/07, Roman Haefeli [EMAIL PROTECTED] 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 [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. it can be downloaded from here: http://romanhaefeli.net/pd/v_abstractions.tar.gz 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 -- 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
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 ? 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 ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
