Tal Benisty

I am currently working on a toolkit for interactive prototyping aimed at design students (and novel users of Max MSP).

I have a question regarding the making of patcher objects which neither my teacher nor searching the internet/forums have been able to answer as of yet:

How can I create patcher objects in such a way that they can read arguments, instead of receiving all their incoming data through their outlets? In a way, I am asking how to create patcher objects that could behave like other max objects that can read arguments. (ex. the object 'Delay' can read an argument specifying a default delay time in ms).

I've added a max patch that could clarify my intentions.

I am looking forward to your suggestions,

I am currently working on a toolkit for interactive prototyping aimed at design students (and novel users of Max MSP). 

Tal Benisty
Msc Student Design for Interaction
TU Delft

patcher-arguments

there are a few exceptions where it does not work, dont

know offhand now, but you will find it out for sure.

if a patcher argument is not there, it becomes 0 as int

to have default value of 20 when no argument is entered.

there are a few exceptions where it does not work, dont
know offhand now, but you will find it out for sure.

if a patcher argument is not there, it becomes 0 as int
and 0. as float. 
i would recommend to do something like:

[loadbang]
[i #1]
[if $i1!=0 then $i1 else 20]

The patcherargs object allows you to retrieve arguments. It works in abstraction as well in subpatches. Arguments are only reported on load, not on instantiation.

I will trythem out tomorrow first thing in the morning and will post my results!

Thank you both for the quick reply!
I will trythem out tomorrow first thing in the morning and will post my results!

I tried JVK's (Johan) method. (see below).

However, it has some limitations, in that it cannot see if the argument is being changed unless the patcherarg object is being banged again. (And then how can you see that the user has changed an argument and subsequently bang patcherarg...?)

Nonetheless, thank you Johan for introducing me to this object, I am sure it will come in handy some time soon.

Roman Thilenius' method, as generously clarified by Iced Dragon (Luis Marques) was as effective as it was simple. Many thanks for that, I didn't believe it would work that beautifully.

I will continue my project and will post my simplifications here, since they will no doubt make ample use of the 't #1' trick.

I tried JVK's (Johan) method. (see below).
However, it has some limitations, in that it cannot see if the argument is being changed unless the patcherarg object is being banged again. (And then how can you see that the user has changed an argument and subsequently bang patcherarg...?)
Nonetheless, thank you Johan for introducing me to this object, I am sure it will come in handy some time soon.

I will continue my project and will post my simplifications here, since they will no doubt make ample use of the 't #1' trick. 

From a historical perspective, the patcherargs object was introduced quite a while after the option to use the number arguments (#1 etc), which is a system limited to 9 arguments. Note that you don't need to use a loadbang; patcherargs will always output upon load. If you want to stick to the patcher model, rather then using abstractions, you could make a button somewhere that triggers all patcherargs objects trhough send and receive objects.

I have been toying around with all the comments you gave me so far and I built the following modified Above patch. It is different from Luis Marques' patch in that it now has a right inlet which makes it possible to override (and overwrite) the patcher's argument. Thank you Johan for your additional information of patcherarg, I used it in the new patch too.

My last issue is now that of the external subpatching (as used by Luis Marques). The patches I'm working on are meant for absolute max beginners and will already be present on a template maxpatch. Therefore, all the patches I'm using need to be self-contained, and can not depend on the presence of additional files (which I'm pretty sure will not always be copied along from usb stick to usb stick).

I've tried using the object (trigger #1) in a regular (non-external) subpatch but it didn't work.

How can I achieve the same functionality as my modified Above patch, without the use of external subpatching?

1. The Above and Above_main patches (based on Luis Marques, modified by me)

2. My simple experiment with 'trigger #1' in an internal subpatch

My last issue is now that of the external subpatching (as used by Luis Marques). The patches I'm working on are meant for absolute max beginners and will already be present on a template maxpatch. Therefore, all the patches I'm using need to be self-contained, and can not depend on the presence of additional files (which I'm pretty sure will not always be copied along from usb stick to usb stick). 

I've tried using the object (trigger #1) in a regular (non-external) subpatch but it didn't work.  

I've attached: 
1. The Above and Above_main patches (based on Luis Marques, modified by me)
2. My simple experiment with 'trigger #1' in an internal subpatch

The #1 argument is not possible without an external subpatch. as far that i know. You can always have a integer came in the right inlet and that way changes the threshold.

Below is what I suggested. The user should hit the button before using the patch after having modified it.

the oldschool way using #1 is the regular and

when you need more than 9 arguments you can use 

it does not work with [p mypatcher] "patcher-in-patcher" 

you can use #1 as argument-to-patcher, too, 

and this is where the real fun begins in bigger 

so try this over more than one level now. 

next thing which i will suggest to you is to

eliminate all those numberboxes, messageboxes,

and bangbuttons from your abstractions - when you 

graphic objects in subpatchers eat of tons of 

1. 
the oldschool way using #1 is the regular and
most straightforward/transparent way.

2. 
when you need more than 9 arguments you can use 
[patcherargs] instead.
you can of course also use both systems.

3.
it does not work with [p mypatcher] "patcher-in-patcher" 
patchers, only with files from disk.

you can use #1 as argument-to-patcher, too, 
and this is where the real fun begins in bigger 
projects.
so try this over more than one level now. 
patch/patch/patch ...

next thing which i will suggest to you is to
eliminate all those numberboxes, messageboxes,
and bangbuttons from your abstractions - when you 
are finished programming them.
graphic objects in subpatchers eat of tons of 
CPU and slow your messages down.

ah, i remember now where it does not work: [expr] and [if]!

One more thing to add: [patcherargs] will work in a [patcher] subpatch, however as stated by Roman the #1 #2 arguments won't. The one thing to watch out for in this case is that the [patcher] name will always be returned as the first argument. Another nifty feature of [patcherargs] is that it can parse attributes typed in after the arguments too.

as Roman Thilenius pointed out, I did learn a couple of valuable facts thanks to your responses. I wasn't aware of the graphical objects' weight, this is something I will definitely take into consideration from now on. Thank you Johan for introducing me to patcherarg, it turned out to be the key to achieve exactly what I needed.

I hereby attach 4 'example' patches that I made for my project, all using patcherarg. They go even further in that they mimic Max MSP objects by using the right inlet to override the original settings of the patcher.

I hope this small contribution to the Max MSP community will prove useful to someone else.

Thank you all, it has been very instructive.

as Roman Thilenius pointed out, I did learn a couple of valuable facts thanks to your responses. I wasn't aware of the graphical objects' weight, this is something I will definitely take into consideration from now on. Thank you Johan for introducing me to patcherarg, it turned out to be the key to achieve exactly what I needed. 

I hereby attach 4 'example' patches that I made for my project, all using patcherarg. They go even further in that they mimic Max MSP objects by using the right inlet to override the original settings of the patcher. 

I hope this small contribution to the Max MSP community will prove useful to someone else. 

You are overcomplicating these patches a little bit. Here is how I would re-work your "ABOVE" patch as another example. [patcherargs] still loads the arguments upon instantiation and it can be modified by using the second inlet, there isn't much need for the [change] or [switch] objects, they all go to the same place. It's good practise to remove all ui objects like [button], [toggle] and [number] from your subpatches too, although leaving them in for examples and debugging can't hurt!

However, if a user changes the argument of the patcher during the building of his patch, your version doesn't detect it (nor changes the treshold accordingly). I can't tell novel users to close and reopen the patch they're working on, just because they changed the argument of the 'above' patcher.

If you can add that functionality to your patch in a simpler way than I did, I'd love to use yours.

Hello lh,
your patch is indeed much cleaner.
However, if a user changes the argument of the patcher during the building of his patch, your version doesn't detect it (nor changes the treshold accordingly). I can't tell novel users to close and reopen the patch they're working on, just because they changed the argument of the 'above' patcher.

If you can add that functionality to your patch in a simpler way than I did, I'd love to use yours. 

Yes you are right, I was just assuming that after instantiation they would use the inlet to set the new values. As you did previously, using the main input to bang [patcherargs] would solve this problem. There is no need to close and reopen a patch though, if you are ever in a similar situation, just delete the object and then edit > undo and it will have the same effect.

Hey guys, sorry for the newbie question, I've been looking for that but found nothing... is it possible to state text as patcher argument instead of numbers? I tried but didn't work...

For instance to name [receive] in the subpatch from the [patcher] argument... thnx!!!

Hey guys, sorry for the newbie question, I've been looking for that but found nothing... is it possible to state text as patcher argument instead of numbers? I tried but didn't work...
For instance to name [receive] in the subpatch from the [patcher] argument... thnx!!!


You can use [patcherargs] in combination with [unpack] or [zl nth].

Is not really what I'm tryin to do tho or I don't understand patcherargs very well...

I've built a stupid example patch to try to be more clear...

Let's imagine this in the png is the subpatch... with 1# and 2# the object could take as arguments the first 2 patcher arguments, but I think it works just with numbers...or am I wrong? If i'm right there's a way to create this thing giving names to send and receive (in this example) from patcher arguments?

first of all thank for the help....
Is not really what I'm tryin to do tho or I don't understand patcherargs very well... 

I've built a stupid example patch to try to be more clear...
Let's imagine this in the png is the subpatch... with 1# and 2# the object could take as arguments the first 2 patcher arguments, but I think it works just with numbers...or am I wrong? If i'm right there's a way to create this thing giving names to send and receive (in this example) from patcher arguments?

Your [send] and [receive] objects aren't in the subpatch so they won't take the [patcher] arguments as their own. If they were inside [p example] then it would work. As would [patcherargs]. Here is an example that will hopefully make things a bit clearer for you.

Well... I wouldn't have been solving this on my own... 

Well... I wouldn't have been solving this on my own... 
Thanks again and again!


this is the final version of the gates I was working on. 

They make use of Patcherargs and the Forward object.

Take a look, it might give you some ideas.

this is the final version of the gates I was working on. 
They make use of Patcherargs and the Forward object.
Take a look, it might give you some ideas.

Patcher arguments