Patcher arguments

May 13, 2009 at 1:40pm

Patcher arguments

Hello all,

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,

Tal Benisty
Msc Student Design for Interaction
TU Delft

– Pasted Max Patch, click to expand. –
#43815
May 13, 2009 at 3:09pm

#1 #2 #3 #4 #5 #6 #7 #8 #9

[int #1]

[slide~ #1 #2]

[v somevalue #1]

[t #7 #6 0 bang]

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]

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

-110

#157330
May 13, 2009 at 3:21pm

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.

_
johan

#157331
May 13, 2009 at 11:32pm

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

Tal

#157332
May 14, 2009 at 12:39am

hi,

have a look at this way.

Thanks

Luis Marques

#157333
May 14, 2009 at 10:30am

Hello all,

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.

Thank you all very much.

Tal Benisty

JVK METHOD

– Pasted Max Patch, click to expand. –
#157334
May 14, 2009 at 10:46am

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.

_
johan

#157335
May 14, 2009 at 5:12pm

Dear all,

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?

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

Again, thank you all very much.

Tal Benisty

#157336
May 14, 2009 at 5:22pm

hi,

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.

Thanks

Luis Marques

#157337
May 14, 2009 at 6:00pm

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

_
johan

– Pasted Max Patch, click to expand. –
#157338
May 14, 2009 at 6:23pm

so you already found out 3 things now.

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.

-110

#157339
May 14, 2009 at 6:27pm

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

-pity110

#157340
May 14, 2009 at 8:56pm

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.

lh

– Pasted Max Patch, click to expand. –
#157341
May 15, 2009 at 9:15pm

Dear all,

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.

Tal

– Pasted Max Patch, click to expand. –
#157342
May 15, 2009 at 10:46pm

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!

lh

– Pasted Max Patch, click to expand. –
#157343
May 15, 2009 at 10:57pm

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.

Tal

#157344
May 15, 2009 at 11:02pm

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.

lh

#157345
Jun 16, 2009 at 11:38am

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!!!

#157346
Jun 16, 2009 at 11:58am

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

lh

#157347
Jun 16, 2009 at 5:58pm

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?

excuse a newbie…. Smile

thanx again!!!

#157348
Jun 16, 2009 at 6:11pm

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.

lh

– Pasted Max Patch, click to expand. –
#157349
Jun 16, 2009 at 6:54pm

Well… I wouldn’t have been solving this on my own…
Thanks again and again!

#157350
Jun 17, 2009 at 12:00pm

Hello all,

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.

Tal

– Pasted Max Patch, click to expand. –
#157351

You must be logged in to reply to this topic.