How to get a patcher name (or arg) as a variable
Jan 02 2015 | 11:22 pm
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
- Feb 06 2015 | 11:01 amThis would be a very awesome thing to have. Still wondering if anyone has an ideas here.
- Feb 06 2015 | 11:18 amDo 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
- Feb 06 2015 | 10:10 pmYeah, 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
- Feb 07 2015 | 10:54 amThis 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 calledp test test4 6Inside 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
- Feb 08 2015 | 7:34 pmIf 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.
- Feb 09 2015 | 10:27 am@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 :-)
