[PD] settable receive again

Jonathan Wilkes jancsika at yahoo.com
Sun Jun 10 18:25:30 CEST 2012


----- Original Message -----

> From: "zmoelnig at iem.at" <zmoelnig at iem.at>
> To: pd-list at iem.at
> Cc: 
> Sent: Sunday, June 10, 2012 6:10 AM
> Subject: Re: [PD] settable receive again
> 
> 
> Quoting Jonathan Wilkes <jancsika at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 



More information about the Pd-list mailing list