What's the recommended technique for dealing with default arguments

Jul 30, 2012 at 6:55pm

What's the recommended technique for dealing with default arguments

Suppose I have an abstraction that has references for two arguments #1 and #2

I’d like to be able to make those arguments optional and have the abstraction use predefined values if I don’t supply them when I create the abstraction. I can think of a number of messy ways to do this but I bet someone has already created a nice clean (and efficient) way to handle this.


Jul 30, 2012 at 7:15pm

[patcherargs] might be what you’re looking for – this lets you use attribute style arguments (not entirely sure if it works for bpatchers), eg @argone 1 @argtwo 2, and allows for setting the default for those attributes (As well as defaults for normal attributes, I believe).

Jul 31, 2012 at 3:46am

Ah, I completely forgot about that approach. I’ll take a look.

Jul 31, 2012 at 3:50am

Wow — this works perfectly — thanks so much for the suggestion, it’s exactly what I needed.

Jul 31, 2012 at 4:17am

i use

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

of course this has limits when used for numbers – if zero could be a value
desired by the user this will stop working.


Jul 31, 2012 at 4:25am

Yeah, I need to be able to handle strings, lists and generally any values, I can’t depend on any magic values. But patcherargs does exactly what is needed.

Jul 31, 2012 at 2:48pm

I don’t see any way to use patcherargs when I want to specify arguments for a [route] object.

I currently have abstractions that contain things like

[route #1 #2]

but there does not seem to be any way to set those args dynamically so patcherargs won’t work

Jul 31, 2012 at 6:08pm

1) i seem to remember that # args still work in place even when you have a patcherargs in the patch. maybe i am wrong…

2) upgrade to max6 – route now has inlets to let you specify matches, easily connectable to from patcherargs.

Jul 31, 2012 at 6:15pm

I have had Max 6 since it came out but unfortunately I can’t use it for this particular project.

#args do work but then I’m back to the original problem of setting defaults, I’ll just get 0 if I don’t supply an argument.

Jul 31, 2012 at 7:07pm

Only thing I could think of for your situation, DHJ, is to make a javascript that you pass your arguments into, and it creates the [route] object and the connections for you when the patcher loads. I don’t have Max 5 installed anymore to test with.

Aug 1, 2012 at 1:25am

you said you want to have lists, too – how did you originally plan to use lists with oldschool #args anyway?

Aug 1, 2012 at 4:32am

I can’t use them with old style args, that’s another disadvantage beyond the defaults issue. It would however be very nice of one could create a list as a parameter, perhaps using a bracketing system.

Aug 1, 2012 at 8:27am

* script the route object – done in 5 mins
* use osc-route if yr project permits
* somewhere in the forum are patches that show some trick to make a changeable route with max5 but dont know how to easily find them… try some search with obvious keywords


Aug 1, 2012 at 11:06am

Maybe for you — although I’ve written several standalone javascript objects, I have not done any object scripting.
—- * script the route object – done in 5 mins

osc-route is a very good idea — I’m already using this for other purposes.

Aug 1, 2012 at 3:22pm

ok I admit it was 19 mins…

– Pasted Max Patch, click to expand. –
Aug 2, 2012 at 2:51am

i see, i wanst aware about @args beeing able to use lists.

i sometimes use lists as symbols as #args, but i wouldnt recommend to do this regulary in many abstractions.

IMO if you need to enter a list of 20 elements somewhere as argument, using arguments to patcher becomes pointless,
you could use a messagebox or list object as well in that case.


Aug 2, 2012 at 4:16am

Wow! So one would have to have that stuff for every route object (and perhaps a number of other objects that have similar issues).

Very interesting to see how that scripting is done though. Thanks for posting the example.

Aug 2, 2012 at 4:32am

@Roman I mostly want it for a small numer of arguments (typically 1 to 5) where the later arguments are most likely to be defaults anyway.

The patcherargs will be just fine except I have to remember to deal with route separately (or use OSC-route, that was a good suggestion)

Aug 2, 2012 at 7:46am

you would change (loadmess 22) to (loadmess #1) and make an abstraction out of it so there is no real extra work now. of course it works with only one value right now.


You must be logged in to reply to this topic.