why no scoping for send/receive objects?
I am repeatedly vexed by the lack of scoping for send/receive objects. It
seems like if i make a patcher that sends stuff inside itself, and then i
duplicate that patcher, that it ought to be the norm that the two patchers
won’t communicate. If not the norm, then at least send/receive objects
could take a second argument to prevent global scope (or if it were the
norm, then an argument to specify global).
Is there some technical reason why this has not already been implemented?
It works with abstractions, but not with patchers. Use send~ #0.foo
and receive~ #0.foo for instance. The #0 gets replaced with a four
digit unique random number at instantiation.
Use #0name for local namespaces. Otherwise namespace for send/receive/
table/coll/buffer~./etc is global. Arguments for both designs, but
this is the one Miller chose for simplicity’s sake while having
multiple patchers loaded which intercommunicate.
For more info on the subject of #0, please consult the manual and
mailing list archives.
if you make sends which communicate only
inside the patcher, they communicate only
inside the patcher, seems like the exspected
if you want to send stuff elsewhere (to a
copy of the patcher) you have to use sends
which do not only communicate inside the patch.
how do i make sends which communicate only inside the patcher? that is
what, but so far as i know, it is not possible.
didn’t see joshua’s email, am looking into it…
"It works with abstractions, but not with patchers." So there’s no way to
achieve scoping for patchers? I’m trying to figure this out with the manual
too, but am having trouble.
Try using "pvar"
ok i get it now. I can use the #1 object to do it with patchers if i supply
an argument to the patcher object. this will do.
Quote: george.locke.maxmsp wrote on Tue, 09 May 2006 13:11
> "It works with abstractions, but not with patchers." So there’s no way to
> achieve scoping for patchers? I’m trying to figure this out with the manual
> too, but am having trouble.
s, send, send~, buffer~, coll, and similar
objects with unique names as arguments _are
always working through the whole runtime, even
between collectives and patches if you want,
it is _only neccesary to do something (which is
such a very secret that i wont tell you) when
you _dont want this.
if it does not work for you to send from a
[s thing] to a [r thing] in another patcher
window, then something else is wrong but not
i thought i had figured it out but no.
Roman, what i’m trying to do is prevent the global scope of send and receive
objects. I need to know the special secret >:0
It seems like the #1, #2, etc trick only works for abstractions and not for
patchers. However i like patchers, i prefer working with them.
i’m looking at pvar, and it seems to work pretty well, but it doesn’t send
to subpatchers. pv might work, but i have to send it a bang message in
order to get a value from it. If that’s what i have to do then i’ll have to
send a bang along some global variable that sends to all pv objects in the
entire patch, which is a lot of unnecessary command traffic.
Say i have patch A. inside A is X and Y identical subpatchers. X and Y
have nested subpatchers X_a, X_b and Y_a and Y_b, respectively. I want to
have something that will send from X to X_a and X_b but not to A, Y, Y_a or
One of teh first lessons you learn in computer programming is to avoid
global variables wherever possible!
thanks for your help,
#N vpatcher 274 190 545 426;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 89 127 74 196617 route X_a Y_b;
#P newex 89 103 52 196617 route X Y;
#P newex 89 79 23 196617 r A;
#P connect 0 0 1 0;
#P connect 1 0 2 0;
~ O ~ http://www.kineticsoundsystem.com
Peter McCulloch wrote:
> Now, if we could just get that functionality for send~ and receive~…
We got somthing even better, called pattrforward. You can send messages
directly to a named object.
In general it seems the whole pattr system is what fills the gap of
local variables completely:
A named object is a local variable by the way, the name is only valid
for that patcher. Pattrforward turns any named object into a local
receive object, which is still accessable from outside.
On 11 May 2006, at 22:24, Stefan Tiedje wrote:
> We got somthing even better, called pattrforward. You can send
> messages directly to a named object.
d’oh! Well spotted. I still have a bit of a blind spot for the pattr
stuff, even though I’ve used it quite a lot, so this technique didn’t
nick rothwell — composition, systems, performance — http://