[PD] settable receive again

Jonathan Wilkes jancsika at yahoo.com
Sun Jun 10 19:20:06 CEST 2012

----- Original Message -----
> From: Matt Barber <brbrofsvl at gmail.com>
> To: zmoelnig at iem.at
> Cc: pd-list at iem.at
> Sent: Sunday, June 10, 2012 12:50 PM
> Subject: Re: [PD] settable receive again
> On Sun, Jun 10, 2012 at 6:10 AM,  <zmoelnig at iem.at> wrote:
>>  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),
>>  patch-locality ($0), 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?
> One other thing I'm not clear on - is the point to have a convenient
> way to ensure locality at patch init, or do you want settable receive
> while the patch is running? The latter would provide the former,
> obviously, but I wonder if the latter is actually germane to the
> original complaint. (The latter would also be in most ways
> conceptually the same as dynamic patching connections while the patch
> is running...)

For the purposes of this constrained example-- where I'm _only_ concerned 
with my abstraction that takes $1 and prepends the parent's "$0-" to it-- 
I have the receive set by loadbang.

In my example from the "nonlocal message passing scope" thread I might 
have added a 2nd inlet to reset the symbol, but that's irrelevant here.  The 
main point is that the question "why would you ever want a settable receive" 
has a clear answer, and in this example it's much preferable to the alternatives.


> Matt
> _______________________________________________
> 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