pound-sign arguments in subpatcher
Hello all,
I am new to MaxMSP and just rolling through the tutorials.
Patch 3 of Tutorial 15 shows how to use 2 arguments that get used by a subpatch (WTHITM_scaled).
Within the subpatch the values of the two arguments are accessed by #1 and #2 respectively.
This works within the tutorial patch, but not when I use it in my own patch - MWE screenshot attached. Expected result is an output of 20 in the console.
I tried looking on the forums but did not find an answer that does not include patcherargs.
What is it that I am overlooking?
Thank you in advance & best,
-Se
So simple, yet not explained in the tutorial. Difficult to find simple explanation because everyone knows!
[WTHITM] is an abstraction - (there is no [p WTHITM]
to make an abstraction - open a new file and put your [p contents] in there.
save as a different name than your main patch, in the same folder or somewhere safe like ~max 8/documents/***.
in your main patch type the name of your new abstraction.
than hook it up!
here
in a way it looks strange that [p ] does not accept arguments-to-patcher, mainly because pfft~, poly~ and bpatcher do.
but a [p ] is simply something very different than these buddies. the object might be called [patcher] - but it does not contain a patcher file, it is part of the mother patcher (file) (and we usually call it "subpatcher")
to make it even more complicated for beginners to understand the differene there is a convenient function called encapsulate/deencapsulate which can convert between subpatchers and patcher files. :)
on a note about abstractions. where is the best place to save them?
currently ~Max 8/Packages/custom_folder/patchers/abstractions is the only place I can get them to be recognized universally.
any patcher file should load from anywhere inside the search path.
in max 4 i put my personal collection into /externals, because that is the way i look at them (subjects not to change), and because i did not know better in summer 2000.
in modern max i use a /package, too, there is probably no better place than that.
because you can have "unfinished" and "deprecated" abstractions within that package but outside the search path (e.g. /mypackage/patches-off/) and you also can bundle your patches with their helpfiles, extras or media files all in the same folder.
if you need to share that package between multiple max runtimes you can still add it as search path to the alternative programs.
Thank you gents, this makes it clearer to me :)
I didn't grok that there is a difference between saving the patch as is and the patcher object, for the reasons Roman states.