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

Hans-Christoph Steiner hans at at.or.at
Sun Feb 5 04:20:35 CET 2012


On Feb 2, 2012, at 11:53 AM, Peter Brinkmann wrote:

> 
> 
> On Thu, Feb 2, 2012 at 1:52 AM, Rich E <reakinator at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120204/0784f16e/attachment.htm>


More information about the Pd-dev mailing list