Re: [PD] [PD-announce] soñando satelites, interactive installation using puredata
Nice one! I saw the Gpredict patch in operation yesterday here at Piksel with Victor Mazon and friends. Good luck! M On Thu, Nov 17, 2011 at 12:56 PM, Husk 00 hus...@gmail.com wrote: Hi list, I just want to present to you my last work Soñando satelites [Dreaming Satellites]. It uses puredata (thanks to Alberto Zin among others), Din - din is noise, and gpredict with a patch from David Pello. cheers husk -- Marco Donnarumma Independent New Media and Sonic Arts Practitioner, Performer, Teacher ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com | http://www.thesaddj.com | http://www.flxer.net Director: http://www.liveperformersmeeting.net ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] soñando satelites, interactive installation using puredata
Big HELLO to Victor Mazon from Moscow ! He and Mario De Vega did a great event here at AlteFest (www.AlteFest.tk) in 2010 !! 19 ноября 2011, 14:44 от Marco Donnarumma i...@thesaddj.com: Nice one! I saw the Gpredict patch in operation yesterday here at Piksel with Victor Mazon and friends. Good luck! M On Thu, Nov 17, 2011 at 12:56 PM, Husk 00 hus...@gmail.com wrote: Hi list, I just want to present to you my last work Soñando satelites [Dreaming Satellites]. It uses puredata (thanks to Alberto Zin among others), Din - din is noise, and gpredict with a patch from David Pello. cheers husk -- Marco Donnarumma Independent New Media and Sonic Arts Practitioner, Performer, Teacher ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com | http://www.thesaddj.com | http://www.flxer.net Director: http://www.liveperformersmeeting.net ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ 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] Pd-list Digest, Vol 80, Issue 105
On Fri, Nov 18, 2011 at 6:42 PM, pd-list-requ...@iem.at wrote: Send Pd-list mailing list submissions to pd-list@iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-requ...@iem.at You can reach the person managing the list at pd-list-ow...@iem.at When replying, please edit your Subject line so it is more specific than Re: Contents of Pd-list digest... Date: Fri, 18 Nov 2011 10:17:56 -0500 From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Troubles running Pd-0.43.1test5 on Windows XP To: rolf meesters rolfmeest...@gmail.com You need to include the ./ since it is a local script like ./configure. So its: ./autogen.sh ./configure make .hc autogen.sh is only present in a number of cygwin/usr/share/doc/gettext/examples/. rolf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd_free vs canvas_vis
I guess this is mainly for the Pd devs, Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free. Initially, I designed a workaround where pd_free is enqueued on the guiqueue and invoked a bit later ensuring that it is called after the tree navigation has ended. This works in most cases but not all. Intermittently this will crash Pd when using Jonathan's Nav abstraction which closes the current patch and also opens a new patch (navigation abstraction would be used to go between help files always keeping only one patch open at a time). Attached is Jonathan's abstraction. So, now I started investigating further and it seems that canvas_vis(x,0) closes the patch without any problems and without having to delay anything but this is not enough in and of itself to actually deallocate the actual t_canvas x and other instantiated objects associated with the canvas. So, how could one go about to implement this feature? Ico #N struct 1002-h float x float y; #N struct 1002-p float x float y; #N struct 1002-n float x float y; #N canvas 412 92 649 467 10; #X obj 281 258 f \$0; #X obj 281 185 t b b; #X msg 310 208 clear; #N canvas 450 249 573 425 \$0-p 0; #X obj 40 40 struct \$0-p float x float y; #X obj 40 62 route click; #X obj 40 84 b; #X obj 40 106 outlet; #X obj 42 132 drawpolygon 0 1 0 -7 0 0 1 0 1 -7 5 -7 5 -4 6 -4 6 -6 5 -3 1 -3; #X obj 42 167 drawpolygon 0 1 11 -5 11 -5 8 -5 8 0 9 0 9 -5; #X obj 42 189 drawpolygon 0 1 18 0 18 0 14 0 13 -1 13 -4 14 -1 14 -5 17 -5 17 -3 14 -3 18 -3 18 -4 19 -4 19 -5 20 -5 20 -2 21 -3 21 0 23 0 22 -1 23 -1 23 -3 24 -2 24 -5 25 -5 25 -4; #X obj 42 237 drawpolygon 0 1 27 -7 27 -8 28 -8 28 -7 27 -7; #X obj 42 259 drawpolygon 0 1 27 -5 27 0 28 0 28 -5 28 -5; #X obj 42 281 drawpolygon 0 1 31 -4 31 -1 32 -1 32 -5 35 -5 35 -1 36 -1 36 -4 35 -4 35 0 32 0; #X obj 42 316 drawpolygon 0 1 39 0 39 -5 40 -5 40 0 44 0 44 -5 43 -5 43 0; #X obj 42 338 drawpolygon 0 1 47 0 50 0 50 -1 51 -1 51 -2 48 -2 50 -3 47 -3 47 -4 48 -4 48 -5 51 -5 52 -5; #X obj 42 373 drawpolygon 0 1 0 2 52 2; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X restore 44 175 pd \$0-p; #N canvas 598 281 534 314 \$0-h 0; #X obj 40 142 drawpolygon 0 1 0 -7 0 0 1 0 1 -7 1 -4 5 -4 5 0 6 0 6 -7 5 -7 5 0; #X obj 40 177 drawpolygon 0 1 9 -4 9 -1 10 -1 10 -5 13 -5 13 -1 14 -1 14 -4 13 -4 13 0 10 0 10 -4; #X obj 40 212 drawpolygon 0 1 17 -5 17 0 18 0 18 -5 21 -5 21 0 22 0 22 -5 25 -5 25 0 26 0 26 -4; #X obj 40 247 drawpolygon 0 1 34 0 29 0 29 -5 32 -5 32 -4 33 -4 33 -3 28 -3 28 -4 28 0; #X obj 40 40 struct \$0-h float x float y; #X obj 40 62 route click; #X obj 40 84 b; #X obj 40 106 outlet; #X obj 40 287 drawpolygon 0 1 0 2 34 2; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X restore 165 175 pd \$0-h; #X msg 44 197 -1; #N canvas 393 226 450 484 navigate 0; #X obj 91 6 inlet; #X obj 91 28 t a b; #N canvas 457 335 450 375 find-this-file 0; #X obj 159 29 inlet; #X obj 159 130 hcs/split_path; #X obj 186 228 f; #X obj 216 228 + 1; #X obj 240 156 sel \$1; #X obj 132 270 f; #X obj 159 53 t b b; #X msg 328 81 0; #X obj 159 103 t a b; #X obj 132 292 outlet; #X obj 332 138 t a; #X obj 332 116 list prepend; #X obj 332 282 outlet; #X obj 108 54 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 159 81 hcs/folder_list ./*.pd; #X connect 0 0 6 0; #X connect 1 1 4 0; #X connect 2 0 3 0; #X connect 3 0 2 1; #X connect 3 0 5 1; #X connect 4 0 5 0; #X connect 5 0 9 0; #X connect 6 0 14 0; #X connect 6 1 7 0; #X connect 7 0 2 1; #X connect 8 0 1 0; #X connect 8 1 2 0; #X connect 10 0 11 1; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 13 0 14 0; #X connect 14 0 8 0; #X connect 14 0 11 0; #X restore 118 50 pd find-this-file; #X obj 235 235 list; #X text 272 234 all path/files; #X obj 91 101 +; #X msg 157 288 symbol \$1; #X obj 130 198 t b a; #X obj 157 310 hcs/split_path; #X msg 157 265 set symbol \, adddollar \$1; #X obj 91 123 moses 1; #X obj 130 145 moses; #X obj 157 103 list length; #X obj 157 125 + 1; #X obj 210 413 pack s s s; #X obj 267 310 loadbang; #X obj 267 332 symbol \$1; #X msg 210 435 \; pd-\$3 menuclose 1 \; pd open \$2 \$1; #X obj 52 150 sel; #X obj 52 71 sel 0; #X msg 52 98 1; #X obj 60 123 == 1; #X connect 0 0 1 0; #X connect 1 0 19 0; #X connect 1 1 2 0; #X connect 2 0 5 1; #X connect 2 0 21 0; #X connect 2 1 3 1; #X connect 2 1 12 0; #X connect 3 0 6 0; #X connect 5 0 10 0; #X connect 6 0 8 0; #X connect 7 0 3 0; #X connect 7 1 9 0; #X connect 8 0 14 0; #X connect 8 1 14 1; #X connect 9 0 6 0; #X connect 10 1 11 0; #X connect 11 0 7 0; #X connect 12 0 13 0; #X connect 13 0 11 1; #X connect 14 0 17 0; #X connect 15 0 16 0; #X connect 16 0 14 2; #X connect 18 1 7 0; #X connect 19 0 20
[PD] Pd in Fedora 15
Dear list, I've recently devided to move to Fedora 15 and i'm trying to set up my audio environment with jack and Pd. I have installed both and both seem to work fine individually, but i get the following error while run both together : JACK error: JackActivationCount::Signal Value = 0 ref = 3 Anyone knows what that means? Nothing bad i hope! Cheers, Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] rt flag?
Hi all, As i wrote in an earlier post i'm trying to set up Pd in Fedora 15 for work in real-time. I m wondering what use is the -rt flag... Does it make any difference at all if you're using Jack in real-time already? Cheers! Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd_free vs canvas_vis
Le 2011-11-19 à 11:39:00, Ivica Ico Bukvic a écrit : Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free. I don't think that you can actually get out of this problem without something like reference-counting. Or else it's going to be quite hackish. I think that Pd should get reference-counting on a large scale. This is not a new idea, but I think that I'm the only one to have considered it realistic. This would solve several problems (freeing symbols, etc) and not just this one. But it would require a somewhat different API and ABI than what we have now, which is the big hurdle. The new API would require only adding function calls to the source, to mark which pointers are still potentially in use. The new API could compile to either the new ABI or the old ABI using header tricks. A C++-based header could make the new API feel more like the old one, by impliciting nearly all of the new calls (by redefining t_atom::operator=). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] rt flag?
Were you able to install the packages from the Planet CCRMA repo to get the real-time kernel? As far as I know that's the only way to get the rt kernel in Fedora without compiling the kernel yourself. (Also notice that Planet CCRMA packages for Fedora 15 is listed as a work in progress.) -Jonathan From: Pierre Massat pimas...@gmail.com To: pd-list pd-list@iem.at Sent: Saturday, November 19, 2011 1:17 PM Subject: [PD] rt flag? Hi all, As i wrote in an earlier post i'm trying to set up Pd in Fedora 15 for work in real-time. I m wondering what use is the -rt flag... Does it make any difference at all if you're using Jack in real-time already? Cheers! Pierre ___ 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] Pd-list Digest, Vol 80, Issue 105
On Nov 19, 2011, at 11:13 AM, rolf meesters wrote: On Fri, Nov 18, 2011 at 6:42 PM, pd-list-requ...@iem.at wrote: Send Pd-list mailing list submissions to pd-list@iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-requ...@iem.at You can reach the person managing the list at pd-list-ow...@iem.at When replying, please edit your Subject line so it is more specific than Re: Contents of Pd-list digest... Date: Fri, 18 Nov 2011 10:17:56 -0500 From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Troubles running Pd-0.43.1test5 on Windows XP To: rolf meesters rolfmeest...@gmail.com You need to include the ./ since it is a local script like ./configure. So its: ./autogen.sh ./configure make .hc autogen.sh is only present in a number of cygwin/usr/share/doc/gettext/examples/ It should be in the root of the Pd source, in pd/autogen.sh, not pd/src/autogen.sh. If its not there, then the source is not complete, and you can get it from git. .hc [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
Re: [PD] get method for Pd
On Nov 18, 2011, at 9:58 PM, Jonathan Wilkes wrote: - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Thomas Grill g...@g.org; pd-list@iem.at pd-list@iem.at; Miller Puckette m...@ucsd.edu; IOhannes m zmoelnig zmoel...@iem.at Sent: Friday, November 18, 2011 7:19 PM Subject: Re: [PD] get method for Pd So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts. How do they get from iemguts to core pd? I don't see a need to do that, so that's a question for someone else to answer. .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd_free vs canvas_vis
From: Mathieu Bouchard ma...@artengine.ca To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at; pd-...@iem.at Sent: Saturday, November 19, 2011 1:30 PM Subject: Re: [PD] pd_free vs canvas_vis Le 2011-11-19 à 11:39:00, Ivica Ico Bukvic a écrit : Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free. I don't think that you can actually get out of this problem without something like reference-counting. Or else it's going to be quite hackish. I think that Pd should get reference-counting on a large scale. This is not a new idea, but I think that I'm the only one to have considered it realistic. This would solve several problems (freeing symbols, etc) and not just this one. Could you go a little into the etc. here? My particular use case is a bit too narrow to justify large-scale changes, and I'm curious what other problems could be addressed by reference counting. But it would require a somewhat different API and ABI than what we have now, which is the big hurdle. The new API would require only adding function calls to the source, to mark which pointers are still potentially in use. The new API could compile to either the new ABI or the old ABI using header tricks. Does that mean you could compile Pd to use old externals (basically everything at present), or new (future) externals, but not both? A C++-based header could make the new API feel more like the old one, by impliciting nearly all of the new calls (by redefining t_atom::operator=). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] pd_free vs canvas_vis
Le 2011-11-19 à 11:47:00, Jonathan Wilkes a écrit : Could you go a little into the etc. here? My particular use case is a bit too narrow to justify large-scale changes, and I'm curious If A_POINTER uses reference-counting, then there will be no more « stale pointers », as data will be kept for as long as necessary until the pointers are gone, even though the data might no longer visible in a patch. There aren't many different cases for the «etc» because there aren't many (standard) datatypes in Pd. But A_SYMBOL refcount is a big deal in several ways, because they're used both for send/receive and for text, two uses that are usually quite different from each other but that can each be a strain on the symbol-table (both the speed of gensym and the ram usage). For future types, however, refcounting would be useful for turning binbuf into an atom type (named A_BINBUF or A_LIST or whatever else). It could also become more inviting for adding various other custom datatypes (from OpenCV, STL, PDP, A_BLOB, GF, and future things). Reference counting is similar to what many programming languages do, and it's also what the UNIX filesystems do : if you open a file in Linux (using fopen() and no fclose() yet) then you can keep on reading/writing it until all fopen() calls get a matching fclose() or equivalent (exit(), or a reboot+scandisk). That's unlike what I remember from Windows, in which you can't delete the file because it's «busy». The new API would require only adding function calls to the source, to mark which pointers are still potentially in use. The new API could compile to either the new ABI or the old ABI using header tricks. Does that mean you could compile Pd to use old externals (basically everything at present), or new (future) externals, but not both? Well, it depends on how much effort is done at runtime to conciliate them. It could be made so that old externals can run in new Pd at the cost of giving up refcount on anything that those externs touch, and perhaps a bigger runtime cost (because adding one more case at each time you decrease the count, and one more case each time you send a message). But overall, even changing all externals is a lot simpler than trying to organise a mark-sweep real-time collector that does not suck (think of all the RAM usage of Java... wait, don't !). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
