pfke

Current patch that i am making on, requires me to make the core patch and then duplicate it several times, with few adjustments.

Now that core patch that i have at the moment, has loads of send / receive objects, and all are named differently, i.e : s b1, s b2, s b3 / r b1, r b2, r b3...

So i will have to duplicate this core patch many times and if the duplicate contains the same send / receive names, it will cause a conflict in the patch.

So my question is: Is there a way for max/msp, to rename these sends/receives automatically, like : s b1a, s b2a, s b3a - r b1a, r b2a, r b3a...?

Now that core patch that i have at the moment, has loads of send / receive objects, and all are named differently, i.e : s b1, s b2, s b3 / r b1, r b2, r b3... 

can-max-rename-sendsreceives-automatically-when-duplicating-patch-chunks

it is possible via an abstraction or within a poly. Which might not be possible in all occasions but might work for you.

I've attached a ZIP with two patches in it open the DynTest to see how it's done.

it is possible via an abstraction or within a poly. Which might not be possible in all occasions but might work for you.
I've attached a ZIP with two patches in it open the DynTest to see how it's done.


See Arguments and Special Characters in Max - $ and # in Documentation.

Hi
See Arguments and Special Characters in Max - $ and # in Documentation.
Cheers


indeed. the names you chose are no good. there are virtually no situations (at least the need of such situations is extremely rare) where you want to give 'global' names to anything at all, let alone sends and receives. this is very basic max knowledge.

however, i doubt if this is in the least bit your fault at all. so i am not 'having a go' at you in the least. read the documentation and you will be enlightened as to how simple it all is...

the "$ and #" (especially #) documentation macciza refers to above is buried in the bowels of the max documentation, as cycling74 have never really seemed to understand that this crucial info should be in Max tutorial number one. or at least Max tutorial number two anyway. sadly this has always been a problem - since i started with Max4.0 anyway. i have no idea why they always hide this info over the years. crazy. strange.

sudden out-the-blue rant and thread hijack over.

Having been bitten several times by this issue very recently, it's seems to me that in hindsight the implicit global behaviour of send/receive was not the best design decision. When I use send/receive to simplify the layout, I've gotten into the habit of always prefixing the name with #0_

It probably didn't matter with smaller patches but once one creates large apps with many abstractions, it's too easy to reuse a variable name. The #0_ word but feels like a hack to me.

Dare i suggest that It might not be a bad idea to create a new set of primitives, perhaps simply called Tx/Rx whose behavior is local unless you specifically add an attribute to make them global. Then deprecate the existing send/receive objects.

Having been bitten several times by this issue very recently,  it's seems to me that in hindsight the implicit global behaviour of send/receive was not the best design decision. When I use send/receive to simplify the layout, I've gotten into the habit of always prefixing the name with #0_

It probably didn't matter with smaller patches but once one creates large apps with many abstractions, it's too easy to reuse a variable name. The #0_ word but feels like a hack to me. 

Dare i suggest that It might not be a bad idea to create a new set of primitives, perhaps simply called Tx/Rx whose behavior is local unless you specifically add an attribute to make them global. Then deprecate the existing send/receive objects.


#0 etc is not a 'hack', it is fantastic. my issue is purely with documentation, nothing else.

whilst your point about how these things should be default local unless declared as global is reasonable to think of now, back in the day it was not, and max's ability to keep compatibility with 20 year old patches is admirable, so all essential objects like this should remain the same. furthermore, global unless declared local is much more in keeping with the historical precedence of other programming languages from back in the day.

you were 'bitten by it' because the documentation ABOUT it is shit, not because IT is crap.

Well, I understand the reasons why it was done the way it was done (which is why I mentioned HINDSIGHT!) but even "back in the day", most decent programming languages encouraged local variables. Note that I do not consider BASIC to be decent (grin).

More importantly, in decent languages that allowed global variables, you had to actually declare them at global scope to get that behavior. The problem with Max is that the names declared at "local" scope (i.e, within a single patcher or abstraction) are implicitly global.

Obviously, legacy is important and one doesn't want to break old code, but there's no reason why improvements couldn't be made to reduce such errors going forward and a Tx/Rx mechanism would help there.

I rely on #1_sendname and #1_receivename, works fine. #0 will work too but it can be nice to know what the actual names are in the instances, in some cases. Or you can do the [prepend 1] --> [route #1] if you're sending from the master patch to a bpatcher.

Doesn't using #1 require that the parent object include an argument? At least #0_sendname will guarantee uniqueness for each individual instantiation.

yes, forgot to mention that, they will need arguments. With #0 they wouldn't. I like to have the ability to send to known bpatchers from the top level, which requires an argument to sort things out. But if everything is local in the bpatchers and you just want the send/receives to be local, #0 is the best (only?) way.

I don't get how to use the #1_bla thing. I've always used the #0_bla route, together with a messagebox #0_bla to report the name on init

Just for reference, could you (seejayjames) post a patch on the use of #1?

i think he asked for "when duplicating" as in while programming, #0 wont help much here.

@roman he said "duplicate this core patch" so when it is a core [patch] it should work.

here's one way to use #1 for send-receive pairs, also it uses #2 as a second argument to do whatever you want:

Can MAX rename sends/receives automatically, when duplicating patch chunks?