Re: [PD-dev] i can has svn commit access?
On Tue, Dec 02, 2008 at 11:43:54AM +0100, Frank Barknecht wrote: Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote: i'd like SVN commit access, so that i can work on improvements to some of the Pd usability issues that have been bugging me lately. i would like to implement multithreaded [soundfiler] read, and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. You're welcome, but take note, that the MAIN branch of Pd in svn is strictly reserved for commits by Miller, so if you want to make changes to [soundfiler] using the sourceforge patch tracker is the way to go. Also, I am sure you already know this but there was a threaded soundfiler by Tim Blechmann some time back. Might be a good idea to check out his code, and also to try and engage Miller before starting the work to ask his opinion on what you want to do (that is, if it's your goal for the changes to make it back into MillerVanillaPd. Pd has a history of people doing lots of great work and fun features that don't get accepted, and that's quite frustrating to watch. Best of luck! Best, Chris. --- http://mccormick.cx ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
hello, i'm maybe wrong, but it look like the pd~ object that is part of 0.42 test release offer a good and generic solution to create thread with pd. So, i'd like to know it i'm to much optimistic, or if work on thread with pd will be obsolet when pd 0.42 will be out. cyrille Chris McCormick a écrit : On Tue, Dec 02, 2008 at 11:43:54AM +0100, Frank Barknecht wrote: Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote: i'd like SVN commit access, so that i can work on improvements to some of the Pd usability issues that have been bugging me lately. i would like to implement multithreaded [soundfiler] read, and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. You're welcome, but take note, that the MAIN branch of Pd in svn is strictly reserved for commits by Miller, so if you want to make changes to [soundfiler] using the sourceforge patch tracker is the way to go. Also, I am sure you already know this but there was a threaded soundfiler by Tim Blechmann some time back. Might be a good idea to check out his code, and also to try and engage Miller before starting the work to ask his opinion on what you want to do (that is, if it's your goal for the changes to make it back into MillerVanillaPd. Pd has a history of people doing lots of great work and fun features that don't get accepted, and that's quite frustrating to watch. Best of luck! Best, Chris. --- http://mccormick.cx ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
hi damien, i would like to implement multithreaded [soundfiler] read, did you have a look at my sndfile external? a threaded soundfiler has to face two issues: - read the file in a separate thread - synchronize the buffers while the first issue is trivial, the second one requires some changes to the public api of pd in order to avoid a recompilation of the dsp chain ... if you just deal with the first issue like sndfiler, you will have audio dropouts when you patches get bigger ... sndfiler used to work without dropouts in the help patches, but not in the rather complex performance patch, i was using those days ... i'd suggest to search the archive of the pd-dev list, iirc i posted a more detailed analysis of the problem a few years ago ... and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. i would like to hear your approach for that, since this is a very interesting issue ... the design of a real-time, multi-threaded dsp engine is actually the topic of my master thesis :) there are two interesting publications about multi-threaded dsp engines, avoiding pipelining techniques: - U. Reiter and A. Partzsch. Multi Core / Multi Thread Processing in Object Based Real Time Audio Rendering: Approaches and Solutions for an Optimization Problem. - S. Letz, Y. Orlarey, D. Fober. Jack audio server for multi-processor machines while the approach of the `letz' paper, as it is implemented in jackdmp is only feasible for graphs with a small number of nodes, the `reiter/ partzsch' paper describes an interesting algorithm for clustering big graphs. unfortunately, implementing the `reiter/partzsch' approach for a pd/max/ nova graph is not that simple ... while the signal flow is explicitly defined in the pd/max/nova graph, the order of accessing shared resources (buffers, busses, ...) is done implicitly ... i had a multi-threaded implementation of the nova engine, only taking the explicit ordering of the signal graph into account. i did not implement the implicit ordering, since the implementation would be quite complex and i didn't have the feeling that pd/max/nova graphs are feasible to represent a multi-threaded dsp engine, because the lack of expressive power concerning resource use ... so, i'd be curious to hear your approach for implementing a multi- threaded dsp engine for pd ... cheers, tim -- [EMAIL PROTECTED] http://tim.klingt.org The most wonderful opportunity which life offers is to be human. Henry Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
So, i'd like to know it i'm to much optimistic, or if work on thread with pd will be obsolet when pd 0.42 will be out. i didn't check the sources, but from the description in miller's icmc paper, pd~ introduces a pipelined approach, i.e. adding one block of latency when audio data is passed from one thread to another. from my understanding, the pd~ approach is static, so a patch would need to be written explicitly for the number of threads ... pd~ has different limitations than max5's poly~, but is still far away from a general solution ... tim -- [EMAIL PROTECTED] http://tim.klingt.org All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
cyrille henry wrote: hello, i'm maybe wrong, but it look like the pd~ object that is part of 0.42 test release offer a good and generic solution to create thread with pd. ok, hello, Miller? if you're reading: is there a roadmap for this sort of stuff? -- damian stewart | skype: damiansnz | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote: i'd like SVN commit access, so that i can work on improvements to some of the Pd usability issues that have been bugging me lately. i would like to implement multithreaded [soundfiler] read, and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. You're welcome, but take note, that the MAIN branch of Pd in svn is strictly reserved for commits by Miller, so if you want to make changes to [soundfiler] using the sourceforge patch tracker is the way to go. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
On Mon, Dec 1, 2008 at 3:09 PM, Damian Stewart [EMAIL PROTECTED] wrote: hey list, i'm Damian, i come from a background in electroacoustic composition and computer science. i've been using Pd for about three years now. i make live electroacoustic performance using Pd+a MIDI keyboard, i work on generative techno patches, and i'm one of the core artists for the RjDj project http://rjdj.me . i'd like SVN commit access, so that i can work on improvements to some of the Pd usability issues that have been bugging me lately. i would like to implement multithreaded [soundfiler] read, and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. i'd also like to be able to work with Chun and Hans-Christoph on their project to rebuild pd.tk . Wow, didn't hear about this (where?) but I'd be so so happy to help. Best Luke thanks d -- damian stewart | skype: damiansnz | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
hello, Tim Blechmann a écrit : So, i'd like to know it i'm to much optimistic, or if work on thread with pd will be obsolet when pd 0.42 will be out. i didn't check the sources, but from the description in miller's icmc paper, does anyone know where to fine this article? pd~ introduces a pipelined approach, i.e. adding one block of latency when audio data is passed from one thread to another. from my understanding, the pd~ approach is static, so a patch would need to be written explicitly for the number of threads ... well, if you can make an threaded_soudfiler abstraction based on pd~ and soundfiler, then it should be ok... pd~ has different limitations than max5's poly~, but is still far away from a general solution ... ok thanks Cyrille tim ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
On Dec 2, 2008, at 8:58 AM, Damian Stewart wrote: cyrille henry wrote: hello, i'm maybe wrong, but it look like the pd~ object that is part of 0.42 test release offer a good and generic solution to create thread with pd. ok, hello, Miller? if you're reading: is there a roadmap for this sort of stuff? Yeah, I'd like to read that ICMC paper, is sucks that ICMC is so lame about publishing their papers. They are really difficult to get, even though I have access to two academic libraries (NYU and Brooklyn Polytechnic) and the NYPL, one of the world's largest. So for people outside of computer music academia, papers in ICMC are as close to good as not published at all. ICMC should follow the example of conferences like NIME (http://nime.org/ ), where all of the papers are available online and are freely downloadable. .hc -- damian stewart | skype: damiansnz | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev http://at.or.at/hans/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
On Dec 2, 2008, at 5:43 AM, Frank Barknecht wrote: Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote: i'd like SVN commit access, so that i can work on improvements to some of the Pd usability issues that have been bugging me lately. i would like to implement multithreaded [soundfiler] read, and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. You're welcome, but take note, that the MAIN branch of Pd in svn is strictly reserved for commits by Miller, so if you want to make changes to [soundfiler] using the sourceforge patch tracker is the way to go. Yes indeed. It is important to reiterate the basic rule of committing that we follow. I think is lightweight yet effective: if it isn't your code that you committed, then always ask before committing. As for implementing substantial changes to soundfiler, I think the way to do it is not to try to get the modifications into Pd-vanilla, there are so many issues of backwards compatibility. Instead make a new object, even if it is largely just a modified version of the original. [sndfiler] is a good example of that. .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
On Tue, Dec 2, 2008 at 12:23 PM, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Yeah, I'd like to read that ICMC paper, is sucks that ICMC is so lame about publishing their papers. They are really difficult to get, even though I have access to two academic libraries (NYU and Brooklyn Polytechnic) and the NYPL, one of the world's largest. So for people outside of computer music academia, papers in ICMC are as close to good as not published at all. ICMC should follow the example of conferences like NIME (http://nime.org/ ), where all of the papers are available online and are freely downloadable. I agree wholeheartedly. I'm actually trying to decide right now whether to publish something at ICMC or at NIME, and this makes the decision a lot tougher. (Specifically because my university is hosting ICMC next year, so it would make more sense for me, but on the other hand I want the paper made available.) Fortunately many people are just posting up their papers on their own websites, maybe Miller could do this. However, I suggest everyone who this bothers to email the admin for ICMC 2008, and ask for a copy of the paper: http://www.icmc2008.net/contact Steve ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
Fortunately many people are just posting up their papers on their own websites, maybe Miller could do this. I don't know which paper was being talked about but they should all be up there on my website :) M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
hello, i had a look there, and did not find anything that could talk about pd~ ... so, i'm still searching for information about this. Cyrille Miller Puckette a écrit : Fortunately many people are just posting up their papers on their own websites, maybe Miller could do this. I don't know which paper was being talked about but they should all be up there on my website :) M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
On Tue, Dec 2, 2008 at 2:43 PM, Miller Puckette [EMAIL PROTECTED] wrote: Fortunately many people are just posting up their papers on their own websites, maybe Miller could do this. I don't know which paper was being talked about but they should all be up there on my website :) I figured! But I think they're referring to this year's ICMC, it looks like your site lists papers up to 2007. Specifically I assume this is what is being referred to: Miller Puckette, Thoughts on Parallel Computing for Music However I noticed beside this it says panel session, not paper session, so maybe it was not actually a written document but only an oral discussion. Steve ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
On Dec 2, 2008, at 2:43 PM, Miller Puckette wrote: Fortunately many people are just posting up their papers on their own websites, maybe Miller could do this. I don't know which paper was being talked about but they should all be up there on my website :) Rumor has it there is a paper about the pd~ thread stuff somewhere. .hc M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All information should be free. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-2379781 ] selecting underneath
Bugs item #2379781, was opened at 2008-12-02 22:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2379781group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: selecting underneath Initial Comment: version: Pd version 0.40.3-extended-20080721 os: vista problem: selecting a box on the canvas (message, object whatever) appears to have the z-axis the wrong way around. - if I place two boxes on top of each other then click to select the top one it actually selects the box underneath. This is more frustrating than it sounds, because after every copy-paste operation (especially with large groups of boxes) I attempt to move the items I have pasted and ruin my tidy layout from before - or worse still - not see that the boxes are selected (because the highlight is hidden) and end up with a big tangle of wires. Sorry if I've got the protocol wrong for reporting bugs, please e-mail if you need more info petemcpartlan at yahoo dot co dot uk, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2379781group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-2379781 ] selecting underneath
Bugs item #2379781, was opened at 2008-12-02 22:07 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2379781group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: selecting underneath Initial Comment: version: Pd version 0.40.3-extended-20080721 os: vista problem: selecting a box on the canvas (message, object whatever) appears to have the z-axis the wrong way around. - if I place two boxes on top of each other then click to select the top one it actually selects the box underneath. This is more frustrating than it sounds, because after every copy-paste operation (especially with large groups of boxes) I attempt to move the items I have pasted and ruin my tidy layout from before - or worse still - not see that the boxes are selected (because the highlight is hidden) and end up with a big tangle of wires. Sorry if I've got the protocol wrong for reporting bugs, please e-mail if you need more info petemcpartlan at yahoo dot co dot uk, -- Comment By: Nobody/Anonymous (nobody) Date: 2008-12-02 22:41 Message: Actually this reverse z-ordering is considered a feature not a bug by many, because it allows some neat tricks like hiding a clickable GUI-bang behind a canvas object that doesn't receive clicks. Changint the behaviour would break all patches that use this feature. (I have several of them, e.g. ezmenu.pd from http://www.mail-archive.com/[EMAIL PROTECTED]/msg14209.html) If you do the copy-paste operation with Ctl-D (for duplicate) instead of Ctl-C Ctl-V then Pd already shifts the duplicated objects some pixels away so you should see the highlights just fine. (You may stilll miss them when clicking, but multi-level undo would be a different feature wish) Frank Barknecht (who's to lazy to log in...) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2379781group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
