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.
Thanks,
D
[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).
Ah, I completely forgot about that approach. I'll take a look.
Thanks,
D
Wow --- this works perfectly --- thanks so much for the suggestion, it's exactly what I needed.
i use
loadbang
[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.
-110
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.
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
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.
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.
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.
you said you want to have lists, too - how did you originally plan to use lists with oldschool #args anyway?
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.
* 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
p
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.
ok I admit it was 19 mins...
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.
-110
@pure
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.
@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)
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.