jayrope

I am making use of polys and bpatchers in a larger patch (MaxMSP 5.19)

Inside polys i can create specificly named/numbered send & receive objects with either

sprintf %ld_name or sprintf name_%ld (both work).

Arguments for bpatchers don't seem to be able to behave that way:

A bpatcher seems to be able to only substitute #1_name, but NOT name_#1.

I tried using sprintf set name_%ld or %ld_name on a send object inside bpatcher, neither work. The name is correctly shown by a message object attached to sprintf, but the send object doesn't eat this. The mistake must be small.

Thank you very much in advance for any insights!

Inside polys i can create specificly named/numbered send & receive objects with either
sprintf %ld_name or sprintf name_%ld (both work).

Arguments for bpatchers don't seem to be able to behave that way:
A bpatcher seems to be able to only substitute #1_name, but NOT name_#1.
I tried using sprintf set name_%ld or %ld_name on a send object inside bpatcher, neither work. The name is correctly shown by a message object attached to sprintf, but the send object doesn't eat this. The mistake must be small.

spintf-ld_name-versus-bpatcher-arguments

A: There is no way to dynamically set the name of a send object, not even upon it’s instantiation.

B: Upon patch load instead 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.

A: There is no way to dynamically set the name of a send object, not even upon it’s instantiation.
B: Upon patch load instead 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.


It's been like this forever. The documentation is actually clear that hash substitution only works at the beginning of a symbol, but it's easy to misread (it feels like this question crops up at least once a week).

And "beginning" means "beginning": the hash mark has to be the very first character, immediately followed by a single digit. (Also, no #10 or #666666. Digit means digit, not number.)

[send] objects can't be renamed because they send every incoming message to [recieve]s. That includes "set" messages. Continuing tautologically, "every message" means "every message."

It's agreed that giving [forward] objects the ability to popup a list of receives is something deeply to be wished for. I suppose there is some quirky internal reason why Cycling '74 hasn't made this happen yet. But in many ways it would be even more useful then the popup menu [send] provides. The symbol [send] is binding to is there on the screen for all to see; forward ain't so obvious.

It's been like this forever. The documentation is actually clear that hash substitution only works at the beginning of a symbol, but it's easy to misread (it feels like this question crops up at least once a week). 

[send] objects can't be renamed because they send every incoming message to [recieve]s. That includes "set" messages. Continuing tautologically, "every  message" means "every  message."

It's agreed that giving [forward] objects the ability to popup a list of receives is something deeply to be wished for. I suppose there is some quirky internal reason why Cycling '74 hasn't made this happen yet. But in many ways it would be even more useful then the popup menu [send] provides. The symbol [send] is binding to is there on the screen for all to see; forward ain't so obvious.


The set message doesn't work on send, because sometimes you might want to send the message set. forward is the easy solution, but you could script send objects if you want. Put this in an abstraction:

The set message doesn't work on send, because sometimes you might want to send the message set.  forward is the easy solution, but you could script send objects if you want. Put this in an abstraction:


Thank you both for your help. I only just start using dynamic objects in maxmsp, those questions shall disappear soon. Scripting send objects now, being able to double click them for connected receives is too helpful during trouble shooting.

sprintf set %s_name on send object doesn't work