Using patcher arguments to change the names of [send] objects within a patcher

    millenliam
    May 20 2011 | 10:34 pm
    Hey I've built a patcher with many [send] objects in it, and I was wondering if it was possible to use something like patcher arguments (#1, #2, #3 etc...) to change the name of the [send] objects between each instance of it? For example, the send objects names are currently 'load_1', 'save_1', and 'delete_1', but I would like them to be the equivalent of load_#1', 'save_#1', and 'delete_#1' so that I can use the patcher many times but changing the [send] names each time using a patcher argument. However I've tried it and noticed that Max sees the '#1' symbol as part of the [send] name so the patcher argument is ignored.
    Is there anyway to do this? Cheers
    • mzed
      May 20 2011 | 10:37 pm
      The # argument needs to be at the front of a string. #1_something will work, but something_#1 won't.
      mz
    • millenliam
      May 20 2011 | 11:07 pm
      So simple! Works great, thanks mz!
    • laonikoss
      May 20 2011 | 11:22 pm
      You can also try [forward].
    • jayrope
      Jul 12 2013 | 6:43 pm
      But... what if name_#1 is needed? I tried using sprintf set name_%ld (and variations) on a send object, but the send object doesn't seem to receive the name, not even on load. Any suggestions?
    • mzed
      Jul 12 2013 | 6:55 pm
      Look at how set works in the send help file, then look at the post right above yours.
    • jayrope
      Jul 12 2013 | 7:21 pm
      I have read that, thanx. In other words, A: there is no way to dynamically set the name of a send object, not even upon it's instantiation. B: Upon patch load a simple sprintf send name_%s (or %s_name) prepares a forward object to send to the corresponding receive object. Drawback: no display of connected receive objects upon double clicking the forward object. Pity.
    • Roman Thilenius
      Jul 12 2013 | 8:40 pm
      "dynamically" seems to be the exact opposite of "upon instantiation". :)
      i think the requirement to do that from outside is ok.
      think of the special #0 situation and you will see why:
      loading a [forward #0_foo] would be totally useless, because it wont be able to find its [receive #0_foo] bitch and interact with it. so here there is no other option anyway than using something like [loadbang]-[t #0_foo]-[prepend set].
      also, i think you will end up with much more ordentliche and gemütliche patches when there is only one place where you take your arguments-to-patchers in, and then use connections to get a "master" [i #5] to dozens of objects.
      this allows you, among other things, to have an initial state other than "0" in an abstraction, when no argumen has ben set from outside. this is just reproducing how many externals work, too (and i wish they would all do it liks this.)
      -110
    • mzed
      Jul 12 2013 | 9:45 pm
      If you really must have this, then put this in an abstraction:
      However, it seems like bad programming practice.