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 am
      This would be a very awesome thing to have. Still wondering if anyone has an ideas here.
    • Feb 06 2015 | 11:18 am
      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
    • Feb 06 2015 | 10:10 pm
      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
    • Feb 07 2015 | 10:54 am
      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
    • Feb 08 2015 | 7:34 pm
      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.
    • 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 :-)