dhjdhjdhj

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.

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

whats-the-recommended-technique-for-dealing-with-default-arguments

[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.

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.

of course this has limits when used for numbers - if zero could be a value

desired by the user this will stop working.

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

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

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.

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.

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

* 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

* 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

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.

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.


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.

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.

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.

@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)

@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.

What's the recommended technique for dealing with default arguments