Can MAX rename sends/receives automatically, when duplicating patch chunks?
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…?
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.
Oh, cheers, man
Ill check it out, right away ;)
See Arguments and Special Characters in Max – $ and # in Documentation.
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.
#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.
interesting discussion :)
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:
----------begin_max5_patcher---------- 774.3oc6W00ihBCE8Ylj4+.g4UWCEAE221eGlIlBbU6tPKoTclYmr+229Aff BynFcb2D7A.au2dO8bu2Bm2e7AKmH1qPgi82sWXaY8tbDK8XpQrpFvxIC+Zb JtPanSTNVDuA3NiJmMhwSj+UNGpZH51LBMEDZObqFkjnW.VzO+lWs24bn.nB rfvnK4PrvflISPicGYilqt5Vdw94FAfsUbTDv70k6FuQ1ggMrGmA5fuhw2ls zrGVJCbhJl.YGrT.Ehwxcpbp8fSYFgttEv7TnwSiIuvI5ayBaBNHKBRZwGUT lgVq3UKmUjTXGvKj68l1a4bNwSlAVGyRYbiCFdq9h6AVlxh+kAct0il.qNu. xxA5dObaliNLhJSIzlY4ihMdapX4JFUTP9sNKgTHnKCVgig9cuNI+CNAm5Ta yZNIgQU.osupwqB4BaeE18agcsATbdWNKXrzHLeGofDkBsydxNHLkjgEffXf jm6dOIY4bBUzd4.JVtLaJh4rzz1qlYpccMUBriDCuPRDazKWCZqUmcyhtVc3 sm3fN8XVVlLoUSj5sM7pF4Nx5nFbrtXt+TvQmIfZNSiyEPnC8oi175n0U8RO ssdZarQS0o4IgiCLk31OW62ed7gpmkON5hoMIni1e73UiZl+ALi2oxLFeDuk WVz6nJDGIOTGSW6ruxuGRLvbx.Zp5Vfa0wD++vgg+qvgHW+aOGBuH2yc28VX +DZY1asdC3Umsmdi5kKoPeeysYi8ck+leWHR90jHc6gHC9.hDcwksmbsZXIQ GLFMW9a1MinyfhB7Znal9IuKlW85gW8uS7JxKT28qo2IAimEnX46.kht5Tp2 chRMGFb5LZiuxKkP68KkzQRYPObcAaKOtBkkugw1sMZSjBKHz5O8cQ8giGZ3 FRRxAeloNeRRxYx2wThwyoH4rgevoB+4Wc3WMQ0nk2K2XegZSqaJ9bUlnQ1y 7uEpLMGP7kIx7SC2UVi4IDuAIlCRLGjXNHwbPh4fDyAIlCRLGjXNHwbPh4fD yaiDS0Lxa+0USY8Z -----------end_max5_patcher-----------