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 .
thanks d
Yay, more devs! Thanks for the email intro, though I know you already. First off, if you send your sourceforge name, then we'll have it once this process is complete.
.hc
On Dec 1, 2008, at 6:09 PM, Damian Stewart 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 .
thanks d
-- damian stewart | skype: damiansnz | damian@frey.co.nz 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
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Mon, Dec 1, 2008 at 3:09 PM, Damian Stewart damian@frey.co.nz 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 | damian@frey.co.nz 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
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
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
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
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.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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
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
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?
i read it in the proceedings of the icmc 2008
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...
from my understanding pd~ provides a pipelining approach for distributing signal processing to multiple threads ... the soundfiler limitations are a different issue ...
tim
-- tim@klingt.org http://tim.klingt.org
Linux is like a wigwam: no windows, no gates, apache inside, stable.
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?
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 | damian@frey.co.nz 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
------------------------------------------------------------------------ ----
On Tue, Dec 2, 2008 at 12:23 PM, Hans-Christoph Steiner hans@eds.org 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
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
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
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
On Tue, Dec 2, 2008 at 2:43 PM, Miller Puckette mpuckett@imusic1.ucsd.edu 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
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
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.
as i mentioned before, sndfiler works around one limitation of soundfiler, but is unable to work around fundamental limitations of pd's architecture ...
t
It seems there are no objections so I am going to add Damian as a developer. Damian, could you post your Sourceforge ID? I couldn't find it anywhere.
Sorry it took so long, when going thru this process, it is appropriate and even beneficial to nag on this list to be added :)
.hc
On Dec 1, 2008, at 3:09 PM, Damian Stewart 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 .
thanks d
-- damian stewart | skype: damiansnz | damian@frey.co.nz 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
------------------------------------------------------------------------ ----
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