robenkleene

According to several threads in the forums, the most common solution for making send/receives work locally instead of globally is to use the special #0 argument before a name. My understanding of the way this is supposed to work is that the #0 gets replaced by a random four digit string of numbers when your patch is loaded. This dynamically creates a unique name to use in your send and receives (i.e. "#0foobar" becomes "1001foobar" when your patch is loaded. Then, if you load the same patch again, the "#0foobar" in the second instance will become "1002foobar", therefore allowing send and receives to be used without the two patches affecting each other.)

(Doing a forum search for "send receive local" will find numerous references to this technique).

I could only find one reference to this technique in the Max/MSP documentation (in Max Topics):

"#0 has a special meaning. It can be put at the beginning of a symbol argument, transforming that argument into an identifier unique to each patcher (and its subpatchers) when the patcher is loaded. This allows you to open several copies of a patcher containing objects such as send and receive without having the copies interfere with each other."

Sounds great, and it is exactly what I am looking for to prevent multiple versions of the same patch from interfering with each other.

The only problem is I can't seem to get it to work, so I think I must be missing something. Here is a simple test to demonstrate this functionality not working correct (based on my understanding of how it is supposed to work). Create two versions of the patch that follows patch and save them under separate names. Open both patches in Max and change the number box in one of them. The number will get outputted twice, once by each version of the patch showing that the send and receives still working globally.

(This is my first time including a patch in a post so please let me know if I didn't do it correctly.)

Any help or ideas would be greatly appreciated. Thanks!!

According to several threads in the forums, the most common solution for making send/receives work locally instead of globally is to use the special #0 argument before a name. My understanding of the way this is supposed to work is that the #0 gets replaced by a random four digit string of numbers when your patch is loaded.  This dynamically creates a unique name to use in your send and receives (i.e. "#0foobar" becomes "1001foobar" when your patch is loaded. Then, if you load the same patch again, the "#0foobar" in the second instance will become "1002foobar", therefore allowing send and receives to be used without the two patches affecting each other.)

Sounds great, and it is exactly what I am looking for to prevent multiple versions of the same patch from interfering with each other. 

Any help or ideas would be greatly appreciated. Thanks!!


local-sendreceives-using-the-0-trick

if you save your patch as an abstraction and call many instances of 

by abstraction i mean a sub-patch, that you name (i called it zero, 

could be anything), save, and use as an object

>According to several threads in the forums, the most common solution 

>for making send/receives work locally instead of globally is to use 

>the special #0 argument before a name. My understanding of the way 

>this is supposed to work is that the #0 gets replaced by a random 

>four digit string of numbers when your patch is loaded. This 

>dynamically creates a unique name to use in your send and receives 

>(i.e. "#0foobar" becomes "1001foobar" when your patch is loaded. 

>Then, if you load the same patch again, the "#0foobar" in the second 

>instance will become "1002foobar", therefore allowing send and 

>receives to be used without the two patches affecting each other.)

>(Doing a forum search for "send receive local" will find numerous 

>I could only find one reference to this technique in the Max/MSP 

>"#0 has a special meaning. It can be put at the beginning of a 

>symbol argument, transforming that argument into an identifier 

>unique to each patcher (and its subpatchers) when the patcher is 

>loaded. This allows you to open several copies of a patcher 

>containing objects such as send and receive without having the 

>Sounds great, and it is exactly what I am looking for to prevent 

>multiple versions of the same patch from interfering with each other.

>The only problem is I can't seem to get it to work, so I think I 

>must be missing something. Here is a simple test to demonstrate this 

>functionality not working correct (based on my understanding of how 

>it is supposed to work). Create two versions of the patch that 

>follows patch and save them under separate names. Open both patches 

>in Max and change the number box in one of them. The number will get 

>outputted twice, once by each version of the patch showing that the 

>send and receives still working globally.

>#P number 108 66 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

>#P newex 231 71 89 196617 receive $0foobar;

>#P newex 108 102 75 196617 send $0foobar;

>(This is my first time including a patch in a post so please let me 

if you save your patch as an abstraction and call many instances of 
it, it works as it is supposed to.
by abstraction i mean a sub-patch, that you name (i called it zero, 
could be anything), save, and use as an object

>Hi there,
>
>According to several threads in the forums, the most common solution 
>for making send/receives work locally instead of globally is to use 
>the special #0 argument before a name. My understanding of the way 
>this is supposed to work is that the #0 gets replaced by a random 
>four digit string of numbers when your patch is loaded.  This 
>dynamically creates a unique name to use in your send and receives 
>(i.e. "#0foobar" becomes "1001foobar" when your patch is loaded. 
>Then, if you load the same patch again, the "#0foobar" in the second 
>instance will become "1002foobar", therefore allowing send and 
>receives to be used without the two patches affecting each other.)
>
>(Doing a forum search for "send receive local" will find numerous 
>references to this technique).
>
>I could only find one reference to this technique in the Max/MSP 
>documentation (in Max Topics):
>
>"#0 has a special meaning. It can be put at the beginning of a 
>symbol argument, transforming that argument into an identifier 
>unique to each patcher (and its subpatchers) when the patcher is 
>loaded. This allows you to open several copies of a patcher 
>containing objects such as send and receive without having the 
>copies interfere with each other."
>
>Sounds great, and it is exactly what I am looking for to prevent 
>multiple versions of the same patch from interfering with each other.
>
>The only problem is I can't seem to get it to work, so I think I 
>must be missing something. Here is a simple test to demonstrate this 
>functionality not working correct (based on my understanding of how 
>it is supposed to work). Create two versions of the patch that 
>follows patch and save them under separate names. Open both patches 
>in Max and change the number box in one of them. The number will get 
>outputted twice, once by each version of the patch showing that the 
>send and receives still working globally.
>
>#P window setfont "Sans Serif" 9.;
>#P window linecount 1;
>#P newex 232 109 32 196617 print;
>#P number 108 66 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
>#P newex 231 71 89 196617 receive $0foobar;
>#P newex 108 102 75 196617 send $0foobar;
>#P connect 1 0 3 0;
>#P connect 2 0 0 0;
>#P window clipboard copycount 4;
>
>(This is my first time including a patch in a post so please let me 
>know if I didn't do it correctly.)
>
>Any help or ideas would be greatly appreciated. Thanks!!


A #0 #1 or #2 argument only works when the patch is a subpatch of another parent patch. When you open the patch directly the #0 shows up just as #0. However, if you save the patch and then load it as an object in another patch, the #0 will turn into the random number you are expecting.

A #0 #1 or #2 argument only works when the patch is a subpatch of another parent patch. When you open the patch directly the #0 shows up just as #0. However,  if you save the patch and then load it as an object in another patch, the #0 will turn into the random number you are expecting.


Thanks for the replies. Yup I tested it this way and the #0 works as expected when used this way.

Unfortunately I don't think that will solve the problem I am having. Basically I just want to send a value using a "send" in a patch into a "receive" in an abstraction loaded by that patch (and then be able to load multiple instances of the top level patch without them interfering with each other).

The reason this implementation of the #0 trick won't work is that the top level patch would have to know the value used for the #0 in the abstraction.

Thanks again for the replies though, great to know how the #0 actually works.

If you have any other ideas for accomplishing my goal above I'd love to hear them. It seems so trivial that I am surprised at how difficult it is. Basically I think all I want is a "pv" that automatically outputs it's value when it changes...

ok here is a solution. The trick is.... you have to save the patch named "subpatch" as a separate patch. Load that patch as an object into the parent patch in the example (in place of the [p subpatch]). THEN save the parent patch, and load it as a subpatch in another grandparent patch-

The reason formated the arguments for the subpatch they way i did was because #0 needs a symbol at the end of it to work properly. So, I just put in foo at the end of #0 and then added bar at the end of the #1 in the subpatch.

I know this is confusing and I hope it makes sense!

ok here is a solution. The trick is.... you have to save the patch named "subpatch" as a separate patch. Load that patch as an object into the parent patch in the example (in place of the [p subpatch]).  THEN save the parent patch, and load it as a subpatch in another grandparent patch-

The reason formated the arguments for the subpatch they way i did was because #0 needs a symbol at the end of it to work properly. So, I just put in foo at the end of #0 and then added bar at the end of the #1 in the subpatch. 

I know this is confusing and I hope it makes sense!


maybe your solution would be to use a poly, and then targeting the instance you want to communicate with... this doesn't involve #0, and send/receive neither. just use the [in] object in your patch and the "target" message with the [poly] object.

Yup, as far as I am concerned this is a basic shortcoming of Max.

Quote: robenkleene wrote on Tue, 12 June 2007 08:54

----------------------------------------------------

> Basically I think all I want is a "pv" that automatically outputs it's value when it changes...

And in the long run you also want it to only work downward, not upward, if you get what I mean.

Here is an abstraction I made that might be what you need:

http://www.arttech.nl/overridable-pv-with-direct-output.zip

Yup, as far as I am concerned this is a basic shortcoming of Max. 

Quote: robenkleene wrote on Tue, 12 June 2007 08:54
----------------------------------------------------
> Basically I think all I want is a "pv" that automatically outputs it's value when it changes...

#0 doesn't work in a main patch - only in patches stored as abstractions.

Save your patch with some name in your search path and then make several

On 6/12/07 1:44 AM, "Roben Kleene" wrote:

#0 doesn't work in a main patch - only in patches stored as abstractions.
Save your patch with some name in your search path and then make several
instances in another main patch.

On 6/12/07 1:44 AM, "Roben Kleene"  wrote:

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

I am going to try some of them later on tonight.

the #0 trick has been pretty handy for me. though i have a few abstractions within abstractions, and this method doesn't work for me when this happens. is there another way to send a message locally or to all child patches, but not others higher in the tree?

what does #2 do? i couldn't find it in the manual.

the #0 trick has been pretty handy for me.  though i have a few abstractions within abstractions, and this method doesn't work for me when this happens.  is there another way to send a message locally or to all child patches, but not others higher in the tree?

what does #2 do?  i couldn't find it in the manual.

On 30 sept. 07, at 12:53, blairell wrote:

> the #0 trick has been pretty handy for me. though i have a few 

> abstractions within abstractions, and this method doesn't work for 

> me when this happens. is there another way to send a message 

> locally or to all child patches, but not others higher in the tree?

> what does #2 do? i couldn't find it in the manual.

You'll have to pass the #0 to the abstractions within your 

abstraction, by using the "normal arguments" #n (with n > = 1 && n

>
> the #0 trick has been pretty handy for me.  though i have a few  
> abstractions within abstractions, and this method doesn't work for  
> me when this happens.  is there another way to send a message  
> locally or to all child patches, but not others higher in the tree?
>
> what does #2 do?  i couldn't find it in the manual.

You'll have to pass the #0 to the abstractions within your  
abstraction, by using the "normal arguments" #n (with n > = 1 && n
9).

thanks for the reply. where could i find a good explanation of #n? i haven't used it before either and it doesn't seem to be in the help file.

thanks for the reply.  where could i find a good explanation of #n? i haven't used it before either and it doesn't seem to be in the help file.


On 30 sept. 07, at 14:39, blairell wrote:

> thanks for the reply. where could i find a good explanation of #n? 

> i haven't used it before either and it doesn't seem to be in the 

"Arguments: $ and #", p. 8 in "Max46Topics.pdf".

> thanks for the reply.  where could i find a good explanation of #n?  
> i haven't used it before either and it doesn't seem to be in the  
> help file.

i tried to use the #1 argument to reference a coll onject name, but this didn't work. the coll object interprets #1 as "#1", not as the value placed after the patch name

i tried to use the #1 argument to reference a coll onject name, but this didn't work.  the coll object interprets #1 as "#1", not as the value placed after the patch name


> i tried to use the #1 argument to reference a coll onject name, but 

> this didn't work. the coll object interprets #1 as "#1", not as 

This would be great if you could provide a patch, otherwise we can 

> i tried to use the #1 argument to reference a coll onject name, but  
> this didn't work.  the coll object interprets #1 as "#1", not as  
> the value placed after the patch name

This would be great if you could provide a patch, otherwise we can  
only speculate.

in this example (youl have to save the patcher out so it works) you can see coll successfully takes the #1 argument, but not #2.

this is preventing me from having multiple independent banks of coll objects. does anyone know a way of working around this? perhaps a way of setting #1 with a sprintf command?

this is preventing me from having multiple independent banks of coll objects.  does anyone know a way of working around this?  perhaps a way of setting #1 with a sprintf command?


> this is preventing me from having multiple independent banks of 

> coll objects. does anyone know a way of working around this? 

> perhaps a way of setting #1 with a sprintf command?

When you use "#1#2" as a symbol, the only one which will be replaced 

is the first one. You could use [loadmess] to get the arguments at 

initialisation (or [patcherargs]), [sprint] to concatenate the 

strings and then the refer message to [coll]. There might be another 

issue which is that the coll need to exist, in that case refer won't 

do anything, so I added a way to create a [coll] on instantiation.

> this is preventing me from having multiple independent banks of  
> coll objects.  does anyone know a way of working around this?   
> perhaps a way of setting #1 with a sprintf command?

When you use "#1#2" as a symbol, the only one which will be replaced  
is the first one. You could use [loadmess] to get the arguments at  
initialisation (or [patcherargs]), [sprint] to concatenate the  
strings and then the refer message to [coll]. There might be another  
issue which is that the coll need to exist, in that case refer won't  
do anything, so I added a way to create a [coll] on instantiation.

your second example is the path i think ill have to go down, as these coll's are being dynamicly created so that other coll objects can actually refer to them.

im very new to creating these sorts of scripts though, and i dont really understand how what you did actually works. i need to learn how connect the output of another two objects which already exist into that new coll object.

what do you think is the best part in the manual/tuts to learn about this stuff? thanks for your help again ej, its been great.

im very new to creating these sorts of scripts though, and i dont really understand how what you did actually works.  i need to learn how connect the output of another two objects which already exist into that new coll object.

what do you think is the best part in the manual/tuts to learn about this stuff?  thanks for your help again ej, its been great.


> your second example is the path i think ill have to go down, as 

> these coll's are being dynamicly created so that other coll objects 

> im very new to creating these sorts of scripts though, and i dont 

> really understand how what you did actually works. i need to learn 

> how connect the output of another two objects which already exist 

> #P newex 105 174 90 9109513 sprintf %s %s%s.kt;

> what do you think is the best part in the manual/tuts to learn 

> about this stuff? thanks for your help again ej, its been great.

Sure. For other scripting examples, have a look to [thispatcher] help 

file there's a few subpatchers in it about the scripting. In that 

case "newex" is the keyword to create a non-UI object, after that you 

have the x and y position of the object, the width, 196617 is a magic 

number which contains the font informations and the name of the 

object [coll]. One thing you can do is just to copy a coll object, 

and paste in a texteditor which will display something really near to 

> your second example is the path i think ill have to go down, as  
> these coll's are being dynamicly created so that other coll objects  
> can actually refer to them.
>
> im very new to creating these sorts of scripts though, and i dont  
> really understand how what you did actually works.  i need to learn  
> how connect the output of another two objects which already exist  
> into that new coll object.
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 49 176 38 9109513 r $1coll;
> #P newex 105 174 90 9109513 sprintf %s %s%s.kt;
> #P window clipboard copycount 2;
>
> what do you think is the best part in the manual/tuts to learn  
> about this stuff?  thanks for your help again ej, its been great.

Sure. For other scripting examples, have a look to [thispatcher] help  
file there's a few subpatchers in it about the scripting. In that  
case "newex" is the keyword to create a non-UI object, after that you  
have the x and y position of the object, the width, 196617 is a magic  
number which contains the font informations and the name of the  
object [coll]. One thing you can do is just to copy a coll object,  
and paste in a texteditor which will display something really near to  
the script.

I realize this post is ancient, but for posterity I thought I'd mention that what the original poster was looking for was ---. When you put --- at the beginning of a variable name it turns into 3 random numbers when the patch is loaded, meaning multiple instances of the same patch will get different numbers. In addition, this is different from #0 in that if used inside a poly~, the numbers will be the same in each instance because they were all loaded at the same time.

Re: poly~, that should definitely not be the case. #0 should generate a unique four digit number number if used inside a poly~ patch or abstraction.

If for some reason you needed all of the voices within the poly~ to have access to the same #0 value you could provide it as an argument to the poly~ object itself (@args #0). Within the poly~ patch you would refer to that via #1 since it is the first argument.

Re: poly~, that should definitely not be the case.  #0 should generate a unique four digit number number if used inside a poly~ patch or abstraction.

If for some reason you needed all of the voices within the poly~ to have access to the same #0 value you could provide it as an argument to the poly~ object itself (@args #0).  Within the poly~ patch you would refer to that via #1 since it is the first argument.


Yes, that's what I meant. I guess it wasn't totally clear, but I was referring to --- when I said the numbers would all be the same.

Local send/receives? (using the #0 trick)