optional argument in abstraction #1 etc.
Hello,
is it possible to have an optional argument like #1 in an abstraction but have a default value, if the the argument is missing after the abstraction name. I tried my having default values inside the abstraction but if the value for #1 is missing I get 0, which overwrites my internal default value. Any workaround?
thanks and all the best,
frank
lodbang - "7" - [int #1]
[patcherargs] is your friend here, I think.
Hi Roman, I don't understand. If I use a loadbang, then my default number, then the object int with arg #1 I never get my #1 number, if I use the argument in the abstraction. What did I do wrong?
best,
frank
Chris, also [patcherargs] doesn't seem to help me. At least I don't know how.
best,
Frank
Hi Frank,
I think this may be your solution:
---save as "mother patch" or similar, next to the following file somewhere:
---save as 'patcherargs_ex.maxpat'
oh, and here is what (i think) roman was mentioning:
...note that this will not work if you supply an argument of zero, which is why the patcherargs methodology may be more suitable in many cases.
Maybe I try to clarify my question: I have an abstraction [my-abstraction] inside I have a loadbang triggered #1 message to let's say a [+ 50] object. When I don't use an argument in my abstraction like above I want the [*] opject to use 50. But if I use an argument in my abstraction like [my-abstraction 87], the [+] object should get "87" in it's right inlet. If I do [loadmess #1] connected to the right inlet, it will send "0" to the inlet and overwrite the "50"
how do I do that?
Actually here is a patch which hopefully explains my problem.
The Abstraction "my-abstraction.maxpat":
The patcher, using the abstraction
thanks,
frank
Thanks jeff, but unfortunately I want to be able to use "0" as an argument, which wouldn't work this way.
best, frank
Here's your abstraction using patcherargs:
jeff, the patcherargs solution works perfect.
problem solved!
thanks a lot
frank