----- Original Message -----
From: "zmoelnig@iem.at" zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Sunday, June 10, 2012 6:10 AM Subject: Re: [PD] settable receive again
Quoting Jonathan Wilkes jancsika@yahoo.com:
[s parent-$0-$1] [r parent-$0-$1]
That probably wasn't clear. I don't want [symbol parent-$0-$1];
inside my
abstractions I want the parent $0 prefixed to $1 as the symbol. In other words, my abstractions make it so that I don't have to type
"$0-" in every
s/r pair where I want canvas locality which as I said is most of the cases by far. (My abstractions do other stuff which I wrote about in the
nonlocal
scope thread, but that isn't important to this discussion.)
are you talking about canvas-locality (something Pd has no constructs for),
See [sendlocal/receivelocal]
patch-locality ($0),
Yes, that's what I meant.
or hierarchical locality (something like [block~] does, and which many text-based languages do, e.g. {int foo; if(2>1){float foo; /* ... */ } }
also, do you want to be able to build abstractions that have the same property?
See the thread with the subject "nonlocal message passing scope".
using externals like iemguts makes it trivial to have all this, but probably the idea is to have all this in Pd-vanilla (i haven't followed the entire thread yet, due to problems with my mai filters)
Digression: While iemguts and my patch that adds a canvas "get" method are good for prototyping a solution, neither provides a full solution-- that is, whatever idioms we come up with for scope would have to be augmented by use of $0 in table manipulation classes, message boxes, structs, and probably other places I'm not thinking of. That's fine for me, as I'm still exploring the possibilities of scope in pd, esp. with abstractions, but the user learning Pd doesn't need to have two incompatible ways of handling symbol locality.
Tim Blechmann had a neat way of solving this in Nova by declaring variables. I think they default to patch-locality if not declared, though I'm not certain on that. Anyway, his method apparently covers all symbols that are bound to send/receive message-- in message boxes, names of arrays, etc. It looked like a very clean solution except that I don't think it addressed abstraction locality like "this symbol shared by all instances of this abstraction", "this symbol common to all objects from this libdir", "this symbol shared by all instances of this abstraction on the parent", etc.
-Jonathan
fgamsr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list