How to get a patcher name (or arg) as a variable
Hi,
I have a series of patchers that correspond to different tracks. For example, inside patcher 1 is a route object called route /track_1/x and inside patcher 2 is an object that says route /track_2/x
Is there a way for me to make the number in the parent patcher name a variable so that instead of individually changing all of the instances of the number 1 to number 3, I could just copy and paste the patcher and change the parent name "patcher 1" to "patcher 3" and all the contained objects with 1 would change names.
i.e.
I want to be able to copy and paste the patcher named patcher 1, change its name to patcher 3 and have all of the objects inside that used to say things like /route_1 to /route_3
I would like to use the name (or argument) as a variable (like $i sometimes is). In other programs this is done with things called iterators but I am not sure about MAX. Thanks
This would be a very awesome thing to have. Still wondering if anyone has an ideas here.
Do you use patchers or bpatchers?
With bpatcher, you can set an argument in the inspector which can be used with a placeholder (#1, #2, etc.) within the patch. Note that you may need to use cnmat's OSC-route (and its slash feature) rather than route to build the adresses.
With patchers, you can set arguments too, just after the patcher's name.
Have a look here
Yeah, this is what I do. Just to be clear, osc-route is *not* needed for osc routing. Normal route will do just fine, and if you do need to chop up OSC, you can do it with:
regexp [\\w\\.]+
(I'm trying to keep my setup completely vanilla; no externals)
What I ended up doing was writing a little abstraction that handles the back-n-forth between (in this case) my lemurs and Max. Gating, parsing, data storage, that sort of thing. I suggest you do the same, if you need to deal with a lot of OSC. I can't believe I didn't do this years ago, actually.
What *I* ended up doing
This looks like what I wanted to do but when I just type extra arguments to the patcher (in addition to what I title the patcher, in this case test) I see no change in behavior in the object container. Here I make a patcher called
p test test4 6
Inside that I have message boxes with
#0 and #1 but pressing them just sends out those values. Do you mind taking a look.
Also @wetterberg, what exactly do you mean about writing an abstraction? I too use the lemur and would like to better understand what you mean.
Here is my test
If you use patchers like this: [p mytestpatch test4 6], then you should have a look to the patcherargs object.
Now, if you save your patcher [p mytestpatch] as mytestpatchabstraction.maxpat, you'll get an abstraction you can reuse in other patches (as long as you saved the file somewhere in Max' search path).
Just type mytestpatchabstraction in a object box, add eventually arguments, like with regular objects and get their values within the patch with #1, #2, etc.
@Wetterberg: [route /#1/volume/x] won't work, you need to use [route #1/volume/x] and give /track_01 as an argument instead of track_01.
I try too to avoid 3rd parties externals, but sometimes it's difficult (although not in this particular case :-)
you can use sprintf with a #0 or #1 argument, and pass that to your route selector (check the route inlets).
loadmess #1 -> sprintf /%d/volume/x -> `route`That will set your route string selector to whatever your /#1/volume/x is, parsed out by sprintf.