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

May 20, 2011 at 10:34pm

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

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

#57237
May 20, 2011 at 10:37pm

The # argument needs to be at the front of a string. #1_something will work, but something_#1 won’t.

mz

#205035
May 20, 2011 at 11:07pm

So simple! Works great, thanks mz!

#205036
May 20, 2011 at 11:22pm

You can also try [forward].

#205037
Jul 12, 2013 at 11:43am

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?

#255806
Jul 12, 2013 at 11:55am

Look at how set works in the send help file, then look at the post right above yours.

#255813
Jul 12, 2013 at 12:21pm

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.

#255815
Jul 12, 2013 at 1:40pm

“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

#255819
Jul 12, 2013 at 2:45pm

If you really must have this, then put this in an abstraction:

<code>

– Pasted Max Patch, click to expand. –

</code>

However, it seems like bad programming practice.

#255831

You must be logged in to reply to this topic.