Abstractions: How to fill in defaults for arguments that the user didn't write?
One more question for today...
If I create an abstraction such as this:
... then [abstr 100 200] will populate both [f] boxes.
[abstr 100] will populate the left one, but leave the right one as 0.
What if I want to implement a nonzero default for the right-hand [f], which is still possible to override by an argument?
In Pure Data, I'd do:
```
[loadbang]
|
(args 0) msg box
|
[pdcontrol]
|
[pack 100 200] or whatever defaults
|
[unpack f f]
```
... because there is a way, within the abstraction, to get a list of the arguments.
I did a couple of searches for a Max equivalent, but Google didn't turn up anywhere that this is discussed.
The trick, of course, is that the right-hand side needs to respond to the *absence* of a value, where graphical patchers are all about responding to the presence of data.
hjh
Have a look at [patcherargs].
Perfect, thanks... I'd read https://docs.cycling74.com/max8/vignettes/abstractions and https://docs.cycling74.com/max8/tutorials/basicchapter15 which... one of these could link to [patcherargs]? But they don't.
hjh
no arguments results in [t #1] becoming "0", so you can create that behaviour using [if $i1=0 then 16 else $i1] (unless you want the abstraction to allow an argument of 0, too.)
for float it works likewise, for strings you´d need to make use of a gate.
(note that not typing in the first but only the second argument is a situation which does not exist. :) but if it is different data types, you could of corse sort the arguments #1 and #2 based on their type)
> no arguments results in [t #1] becoming "0"
Ah and there's the amusing bit: [patcherargs] does not produce any output at all if there are no arguments. (Here's where, apologies to the Max developers, but Miller Puckette did it better in Pd: You get a bang for no args, so you can react to that.)
So then you have to do something rather humorous, like this (which is tricky to encapsulate because, in an abstraction, the following would return the abstraction's args rather than the parent's).
(... which trick I had to work out awhile back, upon finding that zl.filter produces no output when the result is empty, rather than a bang...)
hjh
with patcherargs... just loadbang your default value first, and you should be okay.
before patherargs existed you could make a simple abstraction inside your abstractions, e.g. [110.loadargs #1 #2 #3 #4 #5 #6 #7 #8 #9] and have either a list or single outputs from it, or whatever you wish. (yes, you can insert "#1" as "#1" and it will be given to the sub sub patch)
"Ah and there's the amusing bit: [patcherargs] does not produce any output at all if there are no arguments."
Arguments where? To the abstraction containing patcherargs or to patcherargs for setting the default values in said abstraction? Sorry to ask this but from your last example it seemed maybe you didn't realize patcherargs can take arguments for the defaults. So for your original issue, something like this gets you the '#2' default value of 5 regardless of whether it is supplied by the user.
[loadbang]
|
[patcherargs 0 5]
|
[unpack 0 5]
--------
As for the documentation, you're right. Cycling consistently leaves something to be desired when it comes to updating older documentation for references to newer objects/techniques (and vice versa).
As for the documentation, you're right. Cycling consistently leaves something to be desired when it comes to updating older documentation for references to newer objects/techniques (and vice versa).
+1
> Sorry to ask this but from your last example it seemed maybe you didn't realize patcherargs can take arguments for the defaults.
Ah, OK, I did miss that. So that's easier then.
I learned patching methodology in Pure Data, but now, because of an administrative story that isn't worth retelling, I need to take over the second semester of a Max course. In terms of forum interactions, that means most of my questions are going to be about "fine print" (the things you find out only when you try to use an object and... gotcha...)... so, apologies in advance for that.
hjh
object reference is usually "complete". availabe in max and online.