Re: [PD] Gem and ieee1394 firewire cam on linux debian
I plan to update the help file for pix_video before hans gets the next extended out the door. cheers, tim On 22/08/2007, at 9:58 AM, Olivier Heinry wrote: Le mardi 21 août 2007 à 22:49 +0200, Tim Boykett a écrit : Apologies for a slight stuff up, The suggestion I made here, I now notice deep in the source, has been made. with the message | device /dev/dv1394/0( to pix_video I could have made this work all those days ago. Cheers, tm in this case, updating the pix_video doc would be sufficient O. On 21/08/2007, at 10:28 PM, Tim Boykett wrote: to have special names for special devices. One possibly solution would be to allow a message to pass a device name to pix_video, then this device name would be used instead of pix_video trying to guess. In that case I might have been able to use a openpanel to point pix_video at the correct /dev/dv1394/0. ___ 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] SMP Questions
Tim Blechmann wrote: With the small exception that, as Hans mentioned, two cores will be of benefit because the graphics process can run on its own core. the benefit is that minimal, that it's hardly worth mentioning ... just run your favorite patch and look at the used cpu time ... (for the patches that i tested, the cpu time used by the gui process is less than 0.1% of the time used by the kernel) It's nice to use vu-meters without affecting the cpu available to audio patches on a core-duo. The UI process gets up to about 5% (of one processor) on my most complex patch; it's nice to keep that separate from the audio, of which I tend to need as much as I can get. I'm not disagreeing, really, it's not that significant, but it's better than nothing. to make use of a multicore machine the only way to utilize all cores is to run several instances of pd, that are connected via jackdmp. Now *there's* an idea. Would that really work? What would be the downside -- aside from the memory needed to run multiple copies of PD? the problems are: - scalability: you need (at least) as many pd instances as cpu cores... it is always the question, if you can manually split your dsp graph in a reasonable way ... That's what the modular design would accomplish. Each module would have, at a minimum, audio outputs and optional audio inputs. Come to think of it, this probably wouldn't work very well unless simple control messages of some kind (OSC, netpd, actual PD messages) could pass between the instances, too -- otherwise, each module would have to be set up and initialized separately, which would be time-consuming in a large system. - performance: jackdmp's dsp graph scheduling is less efficient than pd's (which is less efficient than nova's :) ... so using _many_ pd instances is probably a bad idea - communication overhead: you need to synchronize the instances ... easy for simple controls (OSC or netsend/receive) difficult for shared resources (buffers, busses) So jackdmp wouldn't be good at patching say, 32 different generation modules (constituting entire synthesizers) to a nice long, patchable filter chain to final audio output? Rats. That's critical to this being a viable fantasy. I can imagine a very powerful modular system built on this model. i somehow doubt, that i would make sense to use a jackdmp-style multicore scheduling algorithm for a max/pd/nova dsp graph, which can easily contain thousands of nodes (jack graphs are usually rather small), because of the scheduling overhead ... That's too bad. I'll take your word for it that jackdmp wouldn't be able to manage the inter-process connection in a scalable way -- I'm not familiar with how it works. I'm disappointed, because it sounded like a cheap (and yes, slightly inconvenient -- but better than nothing) way to scale up PD with SMP. however, i was thinking about ways to implement a hybrid system with automatic segmentation of the dsp graph into parallel dsp chains that can be scheduled with a dataflow algorithm ... but it would require lots of performance tests to tweak the heuristics of the graph segmentation ... for now, i had neither time nor funding ... (but maybe it is an interesting topic for my master thesis?) I can tell you're talking about the *right* way to do all this. I'm just hoping there's some interim possibility, because even by this time next year, we'll be seeing a lot more n-cores where n 2. Best of luck to you in your endeavors, Tim (especially Nova). Phil ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Starting with subpatches
Hi, im trying to create a subpatch like the colored boxes of the patch i attach (open _KINOKO.pd). These are my steps: I create an object called [pd c]. A new pd window appears. Inside this new window I create an [inlet] and an [outlet] object and i press the second button of my mouse and chose Properties. Then I select select graph on parent and a grey rectangle appear on the main patch window and a transparent with red border rectangle appear in the subpatch window. What is the next step? I found info about subpatches but nothing about this.. br. GARFF _ Descarga gratis la Barra de Herramientas de MSN http://www.msn.es/usuario/busqueda/barra?XAPID=2031DI=1055SU=http%3A//www.hotmail.comHL=LINKTAG1OPENINGTEXT_MSNBH kinoko.tar.gz Description: GNU Zip compressed data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SMP Questions
On Tuesday 21 August 2007 22:25, Tim Blechmann wrote: i somehow doubt, that i would make sense to use a jackdmp-style multicore scheduling algorithm for a max/pd/nova dsp graph, which can easily contain thousands of nodes (jack graphs are usually rather small), because of the scheduling overhead ... however, i was thinking about ways to implement a hybrid system with automatic segmentation of the dsp graph into parallel dsp chains that can be scheduled with a dataflow algorithm ... but it would require lots of performance tests to tweak the heuristics of the graph segmentation ... for now, i had neither time nor funding ... (but maybe it is an interesting topic for my master thesis?) Have you considered delegating these worries to something along the lines of threadweaver, which is designed for just this? http://developer.kde.org/documentation/library/cvs-api/kdelibs-apidocs/threadweaver/html/index.html robert. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] difference send and using msg with ;
On Wednesday 22 August 2007 13:18, Mathieu Bouchard wrote: making DS and pointers work again. The reason I ended up abandoning data structures was, as far as I could see, the only way to get data from them was by polling them. Which I found ridiculous. I found it was much easier and less buggy to simply abuse the provided widgets. In my idle moments staring at the screen (often battling pd lists) I've been considering how I would go about scratch-writing a pd-alike with no legacy requirements. So I have a whole bunch of mad ideas about how things should really be done and you probably shouldn't listen to me. robert. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem and ieee1394 firewire cam on linux debian
Tim Boykett schrieb: Apologies for a slight stuff up, The suggestion I made here, I now notice deep in the source, has been made. with the message |device /dev/dv1394/0( to pix_video I could have made this work all those days ago. It should be documented in the help patch though ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SMP Questions
One of the limitations with the Pd DSP chain *is* it's style of modularity. The stream is broken down into indivisible blocks. The tree is parallel at the top, but as you go down the tree, it becomes more and more serial. There would be a bottleneck, where the parallel processes aren't used. In order to get a generic speedup, those indivisible blocks have to be divisible. And this is not always possible-- afaict, it is just a problem of scheduling ... scheduling a serialized (topologically sorted) dsp graph is very easy and very efficient ... just iterate over an array (nova) or a memory region (pd) ... it is actually scheduled in advance ... a parallel dsp graph scheduler would introduce some dispatching code between the nodes ... probably we need to maintain ready/waiting queues that we have to access in order to make our scheduling decisions ... which is way more expensive than just going to the next node in a dsp chain ... so for small parallel graphs like: osc~ line~ | / | / *~ | dac~ the parallel execution of osc~ and line~ is probably more expensive than running osc~-line~-*~-dac~ so i don't think, it is a problem of splitting up indivisible blocks, but rather to combine these indivisible blocks to reasonably large serial chunks ... You'd have to start almost from scratch to design an ideal parallelized Pd. yes, probably :) tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs 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] Gem and ieee1394 firewire cam on linux debian
Tim Boykett schrieb: Apologies for a slight stuff up, The suggestion I made here, I now notice deep in the source, has been made. with the message |device /dev/dv1394/0( to pix_video I could have made this work all those days ago. I should be documented in the help patch though ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SMP Questions
That's too bad. I'll take your word for it that jackdmp wouldn't be able to manage the inter-process connection in a scalable way -- I'm not familiar with how it works. I'm disappointed, because it sounded like a cheap (and yes, slightly inconvenient -- but better than nothing) way to scale up PD with SMP. if you can split your pd patches to a small number of instances (say 10), you'd probably have some benefit ... running 50 instances of pd is probably not a good idea ... cheers, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs 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] Gem and ieee1394 firewire cam on linux debian
Le mardi 21 août 2007 à 22:49 +0200, Tim Boykett a écrit : Apologies for a slight stuff up, The suggestion I made here, I now notice deep in the source, has been made. with the message |device /dev/dv1394/0( to pix_video I could have made this work all those days ago. Cheers, tm in this case, updating the pix_video doc would be sufficient O. On 21/08/2007, at 10:28 PM, Tim Boykett wrote: to have special names for special devices. One possibly solution would be to allow a message to pass a device name to pix_video, then this device name would be used instead of pix_video trying to guess. In that case I might have been able to use a openpanel to point pix_video at the correct /dev/dv1394/0. ___ 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] difference send and using msg with ;
On Tue, 21 Aug 2007, Robert Scott wrote: So following this pattern, will 0.42 be a compatibility-breaking redesign replacing insane messages with LISP-like lists of lists and atoms? In DesireData, as soon as I'm done reprogramming the GOP feature (which has been dragging for a while and is driving me mad) I will work towards making DS and pointers work again. I will be working at the atom level on three different additions that have something in common: deallocatable symbols, listatoms, and simplified pointers. All three involve reference counting (I won't involve mark-and-sweep in this). Also, listatoms won't be chains of pairs (linked-lists) as they are in LISP; they will be more like LISP vectors, or in pd internals vocabulary, t_binbuf (which might gain in getting renamed) or argument lists. (now I'd like to know: should those lists be mutable or not?) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] audio drop-outs when resizing tables??
On Mon, 20 Aug 2007, Tim Blechmann wrote: On Sun, 2007-08-19 at 11:09 -0700, Miller Puckette wrote: Resizing large memory objects in a real-time thread can block as the OS pages other memory out to disk... so the operation is never safe unless done in a separate thread. what's the problem with using a separate thread for non-realtime operations? Because those threads are woven by illegal Mexican immigrants who steal the jobs of citizens of California, that's why! _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Starting with subpatches
Le mercredi 22 août 2007 à 00:40 +0200, Javier García a écrit : Hi, im trying to create a subpatch like the colored boxes of the patch i attach (open _KINOKO.pd). These are my steps: I create an object called [pd c]. A new pd window appears. Inside this new window I create an [inlet] and an [outlet] object and i press the second button of my mouse and chose Properties. Then I select select graph on parent and a grey rectangle appear on the main patch window and a transparent with red border rectangle appear in the subpatch window. What is the next step? If you add a number box or any slider/widget and position it inside the red border triangle, then close the subpatch, your widget shoudl show on the parent patch. The GOP is greyed out once you open the subpatch. that's the normal behavior. You may have a look at http://footils.org/cms/show/31 aka GOP done right ++ O. I found info about subpatches but nothing about this.. br. GARFF _ Descarga gratis la Barra de Herramientas de MSN http://www.msn.es/usuario/busqueda/barra?XAPID=2031DI=1055SU=http%3A//www.hotmail.comHL=LINKTAG1OPENINGTEXT_MSNBH ___ 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] difference send and using msg with ;
Hallo, Robert Scott hat gesagt: // Robert Scott wrote: So following this pattern, will 0.42 be a compatibility-breaking redesign replacing insane messages with LISP-like lists of lists and atoms? I think, with the introduction of the [list] object family, many more LISP-like list operations became possible with standard Pd objects. Of course Pd is not lisp, and I doubt, it will ever be one. If you need a more structured container for data items, the data structures of Pd are immensly useful IMO. You can ignore all the drawing stuff easily and just use them as general purpose containers. While messages are kind of volatile things that are basically gone, once you've received them (unless you store them one by one into an object like [list]), data structures also have a more permanent character. If you modify a data item through a pointer, the modified version will be available for future use. This makes applications like the Turing machine I once posted, cellular automata, L-Systems and other grammars etc. very elegant to implement. 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] SMP Questions
On 8/21/07, Tim Blechmann [EMAIL PROTECTED] wrote: to make use of a multicore machine the only way to utilize all cores is to run several instances of pd, that are connected via jackdmp. Now *there's* an idea. Would that really work? What would be the downside -- aside from the memory needed to run multiple copies of PD? the problems are: - scalability: you need (at least) as many pd instances as cpu cores... it is always the question, if you can manually split your dsp graph in a reasonable way ... - performance: jackdmp's dsp graph scheduling is less efficient than pd's (which is less efficient than nova's :) ... so using _many_ pd instances is probably a bad idea - communication overhead: you need to synchronize the instances ... easy for simple controls (OSC or netsend/receive) difficult for shared resources (buffers, busses) one additional problem: some algorithms are exclusively serial This is a problem that some scientists face when they bring their matlab code to run on a cluster. They write the algorithms in serial, then they expect to have it perform faster. The programmer has to know serial vs parallel programming techniques, and when parallelism is possible or not. I can imagine a very powerful modular system built on this model. however, i was thinking about ways to implement a hybrid system with automatic segmentation of the dsp graph into parallel dsp chains that can be scheduled with a dataflow algorithm ... but it would require lots of performance tests to tweak the heuristics of the graph segmentation ... for now, i had neither time nor funding ... (but maybe it is an interesting topic for my master thesis?) Agreed, it is an interesting topic. But maybe a generic (applies to all multi-processor systems) solution is not the best way to go. How about just concerning yourself with one instance, one specific set of hardware (for example, see the Storm-1 DSP from Stream Processing, or (cheaper) a quad core Intel). That would be significant, by itself. One of the limitations with the Pd DSP chain *is* it's style of modularity. The stream is broken down into indivisible blocks. The tree is parallel at the top, but as you go down the tree, it becomes more and more serial. There would be a bottleneck, where the parallel processes aren't used. In order to get a generic speedup, those indivisible blocks have to be divisible. And this is not always possible-- note: not complainin'--hhh--just like to be aware that trying to make parallel a software built for serial calculations is a lot more work than it's worth. You'd have to start almost from scratch to design an ideal parallelized Pd. Chuck tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs ___ 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-gui waiting for connection request
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote: after playing around with debian etch I can't get pd to pop up the gui anymore, pd -verbose just tells me it is using port 5400 and Waiting for connection request... and doesn't do anything. Googling around told me that there were/are other people having the same problem, but no suggestions for solutions so far. So i thought this list would be the right place to ask for advice. Any help? Do you have a loopback network device? Can you send the output of ifconfig? 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] How can I mirror the canvas into a GEM window?
Hello, I'm starting to use puredata recently, and I'd like to know if there exists a simple way to put a real-time mirror of the canvas into a gem window, for example, to overlay the images I want to display with the puredata objects I use to generate them. Someone told me in max/msp there is an object called DesktopJitter that does that. In theory it should be easy, as both the GEM windows and the canvas are displayed by the same graphic card. However, someone told me the graphic objects are managed in a weird way in PD so -even if it's perhaps not related-, I am not sure I can find how to do it. And I have no idea of how the canvas is managed in PD. Some advice? Thanks, Joan PS. Unfortunately, I'm mainly working on Windows. However, if a solution exists only for mac or linux, I'll be happy to hear about it. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
