[PD] [PD-announce] Niblock, Tanaka, Mathews, Donnarumma, Freeth - Concert at CultureLab UK
(sorry for x-post) Dimensions In Sound ~A night of sensor based performances~ A rare chance to see this kind of line-up on one night. Don't miss it. Atau Tanaka http://www.ataut.net/ Marco Donnarumma – Music for Flesh II (Xth Sense Performance) http://marcodonnarumma.com/ Kaffe Mathews http://www.kaffematthews.net/ Ben Freeth http://dm.ncl.ac.uk/benfreeth/ +++ Plus Special Surprise Guest +++ Now confirmed special guest and AV Festival preview, Phill Niblock! http://www.phillniblock.com/ WHENWHERE 7.30pm Wednesday 23rd November 2011 Culture Lab Newcastle University, Grand Assembly Rooms, Kings Walk, NE1 7RU Best wishes, -- 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] fux_kinect
Le 2011-11-22 à 12:24:00, Budi Prakosa a écrit : hi all i got fux_kinect working on my ubuntu 10.04 i updated repo on https://github.com/badgeek/fux_kinect/ You disabled all the RGB code ? What happened ? __ | 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] GridFlow slowness (was: pix_set / pix_gain weirdness)
Sorry for the delay. I almost haven't worked on GridFlow since february. Here's the reply. Le 2011-02-27 à 19:35:00, Matteo Sisti Sette a écrit : On 02/27/2011 06:43 PM, Mathieu Bouchard wrote: Are you trying it with an image size much larger than what you really need to analyse ? No I wan't, but I haven't really tried blob detection. I just tried some very basic image processing such as mixing two images, changing the colors, you know the basic stuff you can find in the example patches, and the CPU was already very loaded with relatively small images. There's a problem with number types... the default number type has a lot more range than what is usually needed, and the other number types aren't so easy to use. If this were dealt with, the average GridFlow experience would be a lot faster. You can see alternate number types in several of the examples. As it is now, each GridFlow grid often takes 2 or 4 times the amount of RAM it needs. It's already optimisable since many years, but so far, you have to learn the extra syntax. OTOH, the looser ranges means you more naturally avoid clipping your RGB space, so that you don't have to think about it. In GEM, you don't even have the option of bigger ranges (all pixel values go from 0 to 255). I was just expressing the fact that the power of manipulating raw pixels with matrices in a patching environment such as Pd results to me frustratingly attractive, where the frustration comes from the fact that you can't achieve enough efficiency to manipulate images of reasonable size Perhaps threaded IO would help with those things : if most [#in] and [#out] plugins used threads, they could use the 2nd CPU that most people have and it would already be a relief. But I think the limitation is mostly intrinsic in the fact of doing it in an interpreted environment. Much of GridFlow is designed to be quite fast in an interpreted environment, by doing lots of work per message so that you don't need to send many messages, but it still is quite inefficient on certain things such as copying too much RAM. Much of this has to do with GridFlow not ever requiring something like [pix_separator] (the [#t] is not an equivalent of [pix_separator]). I mean I don't think gridflow could be much faster than it is, or could it? It probably could be much faster, yes. I just stated 3 ways in which it could. Something that would be great would be a pd/gridflow-like patching environment that would compile your patch into shaders and have the GPU make the computation - but in a completely invisible way Do you know if something like that already exists? There's Quartz Composer, but I wouldn't use that. Also, GPU has some quite harsh limitations. There are things that are hard to do outside of the CPU, and generally, even for things that are doable on a GPU, so much code would have to be half-rewritten to fit on the GPU, that it takes a lot of effort and never will be fully automatic (as long as we're in the current GPU paradigm). __ | 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] GridFlow slowness
Hey, thanks for the reply! On 11/22/2011 11:54 PM, Mathieu Bouchard wrote: There's a problem with number types... the default number type has a lot more range than what is usually needed, and the other number types aren't so easy to use. If this were dealt with, the average GridFlow experience would be a lot faster. Does that really have an impact on speed, not only memory usage? Much of GridFlow is designed to be quite fast in an interpreted environment, by doing lots of work per message so that you don't need to send many messages, but it still is quite inefficient on certain things such as copying too much RAM. I am curious about this in a general and OT way, because I've seen that happen in other interpreted environments and that sounds a lot counterintuitive to me (such in Processing, where the bottleneck is often in the methods that copy all the image pixels): how comes that in those cases copying large amounts of memory is more of a bottleneck than actually doing computations? Just a curiosity, and I understand that the question _may_ be badly formulated... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fux_kinect
Because it only output the video depth Cheers On Tuesday, November 22, 2011, Mathieu Bouchard ma...@artengine.ca wrote: Le 2011-11-22 à 12:24:00, Budi Prakosa a écrit : hi all i got fux_kinect working on my ubuntu 10.04 i updated repo on https://github.com/badgeek/fux_kinect/ You disabled all the RGB code ? What happened ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC -- Budi Prakosa house of natural fiber (HONF) yogyakarta new media art laboratory wora wari A80/6 baciro yogyakarta indonesia http://www.natural-fiber.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GridFlow slowness
On 11/23/2011 12:28 AM, Mathieu Bouchard wrote: But usually, the problem is not that the memory copying takes longer, it might just be that it takes a too big percentage compared to other tasks. There's also the problem that making copies takes more active RAM, which means that the SRAM has to be swapping,... But do any of these factors change when using an interpreted language or environment as opposed to doing this natively (e.g. in C++)? I mean, when the bottlenecks of copying ram are discussed, I sometimes get the impression that I'm being told: this is the part of code where the overhead of doing things in java (or whatever) rather than c++ is biggest, which is what I find counterintuitive. Or is it just a misunderstanding of mine? Sorry if this is too much OT but since you kind of mentioned it you woke up an existing curiosity of mine and I ask because it seems you know about it ;) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd-l2ork 20111122 now available
In the spirit of Thanksgiving, DISIS/L2Ork is pleased to announce yet another release of pd-l2ork. Recent fixes include: 2011-11-22 *Ability to move/resize red GOP rectangle via GUI *Allowed GOP-enabled objects to be resized lower than what the default nlet spacing allows *Limit GOP resizing to the size of the text (if hidetext is not enabled on GOP-ed objects) 2011-11-15 *Fixed bug where Save As did not always add .pd extension to the file *Base path (for open/save dialog) is now updated when opening file from the command line to the directory of the file being opened 2011-11-13 *fixed graph-on-parent enable/disable does not activate undo/redo on the parent window (or the gop-ed patch unless it is open) *improved verifyquit mechanism to accomodate abstractions *fixed bug where hide text value was not properly interpreted by the canvas apply redo/undo *fixed stray stderr tcl/tk errors 2011-11-11 *Reenabled universal copy/paste (forgot to uncomment some parts) *Universal copy/paste also resizes the canvas as per original script 2011-10-25 *Fixed a monster segfault bug that occurred when using toggling graph-on-parent and cut in succession (usually in combination with undo/redo). 2011-10-24 *Added undo/redo for creating new objects For additional info please see the Changelog at: http://l2ork.music.vt.edu/data/pd/Changelog Download from: http://l2ork.music.vt.edu/main/?page_id=56 We can be also found on git (thanks to Deba and Hans for all the help!) at: https://github.com/pd-projects/pd-l2ork Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
