I too have fell victim to the failed-to-reply-to-all bug, below is the message I meant to post a day ago..
Cheers, Rich
---------- Forwarded message ---------- From: Rich E reakinator@gmail.com Date: Wed, Feb 1, 2012 at 3:31 PM Subject: Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion? To: Peter Brinkmann peter.brinkmann@googlemail.com
I do think it is important to separate these things into bite size chunks (I think IOhannes mentioned this as well during his LAC talk). Peter, your blog post talks of creating an API for editing patches (herehttp://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/), and while I look forward to these capabilities, I think this is also a separate job as to the one Miller proposed on this thread, which I see as taking care of the static state in pd. I don't think I could prioritize these two different jobs, but I'd say multiple instances allows us to definitively crush max, as we'll have a pd vst. :)
On Tue, Jan 31, 2012 at 4:44 PM, Peter Brinkmann < peter.brinkmann@googlemail.com> wrote:
I see the next important step as making the general cases easier to
handle. A per-thread context such as IOhannes and Peter describe above seems like the best approach to allowing a program to run multiple instances of pd in a much more predictable manner, while it still allows for backwards compatibility (via a default 'legacy' context). I see parallel processing as a different topic, although it will be easier to implement once the static variables are taken care of.
Actually, I would sum up the thread slightly differently. We've touched three different topics: support for multiple instances of Pd, a potential refactoring of Pd on top of a library like libpd, and support for concurrency. As I see it, those three issues are largely orthogonal to one another. In particular, I'd rather not entangle multiple instances with multiple threads.
As far as libpd is concerned, the most important part is to achieve support for multiple instances. Tying instances to threads wouldn't be too helpful because there are lots of legitimate use cases where one thread needs multiple instances, as well as use cases where one instance is shared between threads.
The next step would be a refactoring of Pd, towards a more portable user interface. There's been an ongoing thread at Pd Everywhere on porting the UI to mobile devices ( http://noisepages.com/groups/pd-everywhere/forum/topic/cross-platform-mobile...), and I wrote up a few thoughts on my blog ( http://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/).
Support for concurrency comes in third on my list. I already outlined most of my concerns in previous messages, and I also figure that this should be tabled until the other two problems have been solved. Cheers, Peter
On Thu, Feb 2, 2012 at 1:52 AM, Rich E reakinator@gmail.com wrote:
I do think it is important to separate these things into bite size chunks (I think IOhannes mentioned this as well during his LAC talk). Peter, your blog post talks of creating an API for editing patches (herehttp://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/), and while I look forward to these capabilities, I think this is also a separate job as to the one Miller proposed on this thread, which I see as taking care of the static state in pd. I don't think I could prioritize these two different jobs, but I'd say multiple instances allows us to definitively crush max, as we'll have a pd vst. :)
I harbor no hostility to Max, but I agree that getting rid of global state and allowing multiple instances should be the first order of business. Any ideas? Cheers, Peter
On Feb 2, 2012, at 11:53 AM, Peter Brinkmann wrote:
On Thu, Feb 2, 2012 at 1:52 AM, Rich E reakinator@gmail.com wrote: I do think it is important to separate these things into bite size chunks (I think IOhannes mentioned this as well during his LAC talk). Peter, your blog post talks of creating an API for editing patches (here), and while I look forward to these capabilities, I think this is also a separate job as to the one Miller proposed on this thread, which I see as taking care of the static state in pd. I don't think I could prioritize these two different jobs, but I'd say multiple instances allows us to definitively crush max, as we'll have a pd vst. :)
I harbor no hostility to Max, but I agree that getting rid of global state and allowing multiple instances should be the first order of business. Any ideas?
The way I see the "editing API" is the converse of the pd-gui --> pd communications: pd messages. My approach is to do it bit by bit. Take a chunk of the current pd-gui --> pd communications and refactor into something that looks like a pd message (Tcl proc calls can look the small, luckily, the syntax is similar in some basic ways).
Ico has recently refactored array moving into a single 'move' command, that's in pd-l2ork. I haven't looked at that yet. But that's the same idea.
.hc
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
On Sat, Feb 4, 2012 at 10:20 PM, Hans-Christoph Steiner hans@at.or.at wrote:
The way I see the "editing API" is the converse of the pd-gui --> pd communications: pd messages. My approach is to do it bit by bit. Take a chunk of the current pd-gui --> pd communications and refactor into something that looks like a pd message (Tcl proc calls can look the small, luckily, the syntax is similar in some basic ways).
Agreed. It's pretty clear how to express most pd-->pd-gui communications in terms of regular messages. The only parts I'm unsure about are arrays and data structures. I sort of see a solution for arrays: When an array changes, send a message that consists of the name of the array and a pair of indices that delimit that range that has changed, and then the GUI can read out the relevant part of the array (libpd already includes an API call for that).
I don't really know data structures in Pd, but I suspect that a similar approach might work, except that we would need to add an API call for reading and writing data structures. Cheers, Peter
On Feb 5, 2012, at 12:46 AM, Peter Brinkmann wrote:
On Sat, Feb 4, 2012 at 10:20 PM, Hans-Christoph Steiner hans@at.or.at wrote:
The way I see the "editing API" is the converse of the pd-gui --> pd communications: pd messages. My approach is to do it bit by bit. Take a chunk of the current pd-gui --> pd communications and refactor into something that looks like a pd message (Tcl proc calls can look the small, luckily, the syntax is similar in some basic ways).
Agreed. It's pretty clear how to express most pd-->pd-gui communications in terms of regular messages. The only parts I'm unsure about are arrays and data structures. I sort of see a solution for arrays: When an array changes, send a message that consists of the name of the array and a pair of indices that delimit that range that has changed, and then the GUI can read out the relevant part of the array (libpd already includes an API call for that).
That makes sense to me.
I don't really know data structures in Pd, but I suspect that a similar approach might work, except that we would need to add an API call for reading and writing data structures. Cheers, Peter
I don't know that code much, so I don't have much to say on it. But I do think that we can start with the easy stuff, then looking at data structures will be easier then.
.hc
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
-
Hans-Christoph Steiner -
Peter Brinkmann -
Rich E