What's the recommended technique for dealing with default arguments

    dhjdhjdhj
    Jul 30 2012 | 6:55 pm
    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
    • MuShoo
      Jul 30 2012 | 7:15 pm
      [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).
    • dhjdhjdhj
      Jul 31 2012 | 3:46 am
      Ah, I completely forgot about that approach. I'll take a look. Thanks, D
    • dhjdhjdhj
      Jul 31 2012 | 3:50 am
      Wow --- this works perfectly --- thanks so much for the suggestion, it's exactly what I needed.
    • Roman Thilenius
      Jul 31 2012 | 4:17 am
      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
    • dhjdhjdhj
      Jul 31 2012 | 4:25 am
      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.
    • dhjdhjdhj
      Jul 31 2012 | 2:48 pm
      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
    • pid
      Jul 31 2012 | 6:08 pm
      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.
    • dhjdhjdhj
      Jul 31 2012 | 6:15 pm
      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.
    • MuShoo
      Jul 31 2012 | 7:07 pm
      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.
    • Roman Thilenius
      Aug 01 2012 | 1:25 am
      you said you want to have lists, too - how did you originally plan to use lists with oldschool #args anyway?
    • dhjdhjdhj
      Aug 01 2012 | 4:32 am
      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.
    • pure
      Aug 01 2012 | 8:27 am
      * 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
    • dhjdhjdhj
      Aug 01 2012 | 11:06 am
      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.
    • pure
      Aug 01 2012 | 3:22 pm
      ok I admit it was 19 mins...
    • Roman Thilenius
      Aug 02 2012 | 2:51 am
      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
    • dhjdhjdhj
      Aug 02 2012 | 4:16 am
      @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.
    • dhjdhjdhj
      Aug 02 2012 | 4:32 am
      @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)
    • pure
      Aug 02 2012 | 7:46 am
      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.