I too have fell victim to the failed-to-reply-to-all bug, below is the message I meant to post a day ago..<div><br></div><div>Cheers,</div><div>Rich<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Rich E</b> <span dir="ltr"><<a href="mailto:reakinator@gmail.com">reakinator@gmail.com</a>></span><br>Date: Wed, Feb 1, 2012 at 3:31 PM<br>Subject: Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?<br>
To: Peter Brinkmann <<a href="mailto:peter.brinkmann@googlemail.com">peter.brinkmann@googlemail.com</a>><br><br><br>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 (<a href="http://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/" target="_blank">here</a>), 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. :)<div class="HOEnZb">
<div class="h5"><br>
<br><div class="gmail_quote">On Tue, Jan 31, 2012 at 4:44 PM, Peter Brinkmann <span dir="ltr"><<a href="mailto:peter.brinkmann@googlemail.com" target="_blank">peter.brinkmann@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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.</div>
</div>
</blockquote></div><br></div>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.<br>
<br>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.<br>
<br>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 (<a href="http://noisepages.com/groups/pd-everywhere/forum/topic/cross-platform-mobile-ui-for-libpd/?topic_page=3&num=15" target="_blank">http://noisepages.com/groups/pd-everywhere/forum/topic/cross-platform-mobile-ui-for-libpd/?topic_page=3&num=15</a>), and I wrote up a few thoughts on my blog (<a href="http://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/" target="_blank">http://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/</a>).<br>
<br>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.<br>Cheers,<br>
Peter<br><br>
</blockquote></div><br>
</div></div></div><br></div>