[PD-dev] Fwd: per-thread storage in Pd in support of pdlib - discussion?

Rich E reakinator at gmail.com
Thu Feb 2 07:52:58 CET 2012


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 at 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 at 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
(here<http://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 at 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-ui-for-libpd/?topic_page=3&num=15),
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120202/f5da61fd/attachment.htm>


More information about the Pd-dev mailing list