send/receive local to patcher
Is it possible to create send/receive objects that are local to the subpatcher they are in? An example of this might be a subpatcher with multiple copies going on within a poly object. Or maybe just not wanting to worry about not using the name again elsewhere in the patch if when creating the original send/recieve, you know it will not be used outside of the subpatch.
Does something like this work? You would need to have [receive~] objects in the main patch for each of your [poly~] instances.
----------begin_max5_patcher---------- 323.3ocqSsraCBCD7r4qvxpGoUfIjf5s9WTopnJGravUfMBunRZTx2dwFnMO HRDQu3Eu6r1yLrduGhrQ2HLD7y32vHzdODxkxl.0uGQJXMo4LiCFoPXLrsBh eWMPz.t7FAfK046dHbnjptPWC4Bv0XXeVI2AWu4yGoACP6vA6JEcTgPvq6K8 gVAJVgq.4kJIKenoRFjlIUaeuRjBc8EGQeJvGSSRrgkw10v1uO6zLxucmVnE 6uTUpFXJ0l6fmmcwehthR7UqhFwTT7iNa40wckfqckDxLTdDMxFVsxYCA2ox C++TNjIMVcebbcSuV2Kt4vfTAD+tv7FKhWZCwIy1bbMRxkpKe63tba9ycLit tJcPNCi93+tetv.RECjZ0IfRNCSljyEpSGZJj7RcqqzyA75Q+8MUJsXBL5BZ eeTpcyAueP9dGDL -----------end_max5_patcher-----------
I recall posting these three characters to a thread before… pv?
My preferred mechanism for passing messages locally and privately within a patch? "They call them ‘patch cords’."
Mine too, but I thought the OP was talking about passing specific signals from poly~ subpatchers out to the main patcher.
you cannot use send/~ receive/~ inside a poly~. period.
this is what i do:
----------begin_max5_patcher---------- 1841.3oc4assjiZCD8YOeEpnxCIa43R23VRsOjuis1ZJrQisxhAW.dlcyVq+ 1it.XvC1Hvf2PkW.qFgnOG0p6VM3u+zBq0IekkYA9Cvm.KV78mVrPIRJXQQ6 EV6C95lnfLU2rhYukr9usVpuTN6q4Jw4.DXcozCA4a1wi29bJaStdvwt1qfK ADj5DEKOhgqffOWbOujDmGGrmoFs+JkGDUNZ7PkLwS82IdUB2FmHF8H9luHu JpPb7w873HVdVcgxgNi+OpgFIexU8M4XdYmwER0hx+1AlVws3w4VKAVqCh2Z A9rrS+3omjGVZHismkkErk8NJa+wbF3WPFPZTh7jMUdD40aRysOjFtOjF5Zj 1vXpqXaEkDDpn+NYJrmu7jCbflW1V2sczUojga.cEZQ7DNA7tAoPnJ1fRQ5S CjTP2OoTJMK3UV3yhQUniOGjmmxWKVDjUfcA3UcSQOiII4dKRBRFCRBO6IIm as7x1cLHIxrmjruEIgPiAIQm8jD8FjDxwdLHI3rmjH2hjPigiar+rmjv2fjb GC+1XuYOGc6DHGCNxcNyQe3D.t5Vw+cUIKRzlSDmAxQNO9bryDOJgxLloTd. bHI5aAGC4hm1Ag0U2obSgJiKDhrxdPLW64bS5CE40AEsbT9UEtTjAK8rQ6Bs pxiXuxRy3Iw0l2VXUixnJyKpdUoui1hqFkIl11Fkr4KrvZKZVXExdoWCRxAV 74aPYe23PydxiOjxxXw4A4Epd8Gbvwn7maeVn40eIXC6p2bqlAKr1lxCShkJ Qi6TJt7wIhFpryjGOq2pdDGbnkaNOIIZcP5q7L95HViYBwZhfX99fbVNWqOX X08w2eHUtW+5iEKNPLF6x1jlDE0XnzW40VtRH6U9F1a7v7cpw5La0nVK0rbZ rZsg7KV0pVdTRdWYYIEocjoxf.aWdrh5tX4Gp9v0XEHr4EduGoN7JUqSaR1u mooVKqRwZm7KJ8ZMD9ngWrldx3cQSpJPgzmH3K8cca+WWRhNMj2Z.fqFD3Fd 45K0qrd+7ige+3GAvNnXOUfAOUVGD6Kiq1OF19+eLbFKBfLhhQPu1ycoebL8 gww3aww5J8UUBwomn2JhGbB30o8bQQqQ5Htd92mOCxCis8Lvc8XkgzCZoAe6 ICmtPd5sIRtu0F3gLagFc+OSAOaTRE3dkSg8XmTg1u6CHiBSHCsSWiICmYKY nexl4UTuODCnCWKSVtzZ0C94CVe5JOaWDsO.1aNCXjXalJD61GH6OmgrXKg8 GxX3rFx1jA.YzbFxDny.fLdVCYa+A.YxbFxTQpV8Gxz+iB4xwssThy2wyj0t 8TWLhhDzueIO38kTrYQ1LNyW3ChpTrBPUj6tVw3COyV9241qQv4IcwBDrEON KOHdCCj7BHHF7qd+FXytf3XVj5MFbB7FOJBrlAREZHKDjm.xXGBREasFneUB Y+o3FEWXGCH2vc0Mj8FWVM8PwH+B3kjTQu9FXuZPJenKECWiopHdLaSxQ8RL mNxfQOGpKCExV2vevSh344jnmfLCOvhCEcnbBoKWEHW0qXfPf0nt6v9mN8T2 4WPfzD4J0ZWAU40amSyRNltobuVEU2EzDygrrbdb0qK4SU0H3h9siGF17sSn lz3gGRDahqP8rQxBIgbU6ipVCC2jeeQisgngNLzHVsIA.zVdpViIBMTCQiyc gFBUdpXtQ1XBQCZ5rzPPWs0EotoFYxL0DoNBbMANCzVih00dvQYrIaQJy0yY 5L4jnxwDTQFFpHNhnSBXPwUPSJ5QAMaSf1.M.IHmUHJ1ylbFZBQOJnQMAZng AMrCYEVfMeZEzjhdTPiXBzfCDZH3JwblKFcFZBQOJngM.ZxJNMHOh1tMwwx2 KZBglI95k0ObXN6oqjK0bOaPJEQJJe4DiLShIKKE7vSXp.S0ZLQvAaHbH2EZ f9miIqZLQnAYZ1r12SFStjyo+I+8TAF6oM8uhTjf3Zo+IaLUvoGVZngktjJA V+xzkfEsZEOEBE.yvOcyt1OXmeMYaiRVGDU700UMFU2dqejYi8Wl1n+8mdYg 4t0+yKch4NC7aPE8S6+F24OKldxYMKYQqkn6DPXLvtA4QgEjWg8LYXrGcL9K ETiBTO8lkgPyHW5UnfWdeXzFA9ulqfFwPeuef2kKmmZqrDhmJPSsVWY9qWZK pCsE0Okkn2uJwwstxJacuJqqATKZXLqX0ack049UVaSrC7Fl1hP00VYq6Taw NFnsxu46y40afgfqJjEwWwsxVvhV2q1ZWeagWiao8zrUu3hRTo+fwvpVig1Z 2k1R5o1Zi0efTZsUa9NZZqSWZKtmZaQsdzZKAgGUs0sKssuNvzVpkZqs2nps jtzVXO0V8qFsPaQtzQUawc4SvumZq10Uo1hGWtsqHY395u02qF25Mtlsc5tc XIITZ1NZdDPlFZX.Ax7aD1cDBMfLwJnoohAQFP0iiIZ41p1JZ7im9WDpAEcC -----------end_max5_patcher-----------
Thanks for letting me know about using patch cords, I hadn’t got that far in the manual yet.
And to everyone else, thanks for the help and examples.
My reason for wanting to do this: a sub patcher is getting crowded and I’d like to avoid having patch cords running across the interface while I’m working. It’s a situation where there is one clock source being sent to several destinations. It would make things a lot cleaner using a send and multiple receives. I’d like to be able to name this something generic like clock, and afterwards, not have to worry about using that same variable name somewhere else without it picking up the messages going on in this subpatch.
I have a feeling the answer is no. I know I could get around this simply by adding a number to the variable name to make it unique. At the same time though, I think in alot of software languages, local and global variables are fundamental and commonplace. I’m just wondering if Max has this capability. So this question is philosophical just as much as it’s practical.
My post above, while it may have sounded simply smart-*ss, was actually expressing my Max programming "philosophy"/practice. send/receive and send~/receive~ use a shared namespace and are best thought of, in my opinion, as global channels of communication, rather than simply as substitutes for patch cords. The original post sounded to me like something that was most appropriate to patch cords, not global transmission/reception.
There are many ways to deal with the "patch cords are messy" problem: object positioning, segmented patch cords, hidden patch cords, color-coded patch cords, etc. Yes, one can use send/receive as a substitute, but it introduces some of the potential problems mentioned, such as indeterminate message ordering and conflicting use of shared names.
I see send/recieve the same way, as global communication. And I always use as few as possible. It would be nice however to have the option to make them local at times… to use them in a different way. Could be as simple as an option in the inspector called "global/local". In certain situations, the solutions for "messy patch cords" really aren’t that great.
You _can_ use send~/receive~ inside poly~, although you may not want to. I tend to agree with many here that patch cords are best.
Here’s an example of dynamically assigning send~ names inside a poly~ to create variable-pass effects (Jitter and MSP) – passing signal or data from one instance of poly~ to the next. Other better ways to do this though, this is really only for example. Was posted here a few years ago, but the attachment is missing for some reason.
One thing that’s helpful is that you can double click a send object and it lists all the send and receive objects with that name. This way you can be sure that it is not being used.
I’ve found that its good practice to always check as it helps to avoid potential problems as a patch grows.
On the other hand, this could create problems when duplicating sub patches because the send/receives will have the same name. I remember coming across a solution to this where they will automatically be renamed. It was something like [send ###-01], I can not remember or find it right now.
Hope this helps and good luck!
Just as a follow-up in case folks are reading this later:
Re: what PID said:
You absolutely _CAN_ use send~/receive~ within a poly~ (unless there’s been a major undocumented change in the API!), and there are several valid reasons to do so. For example, I use it to do dynamic signal routing in situations where a full-on matrix mixer is overkill (or I am dynamically loading processing patches and need my mixing matrix to grow or shrink)
That said, it’s probably not the preferred solution, but it is legal and there are times when it is the best solution. It’s particularly handy in patches (e.g. Max4Live) where you know there cannot be a global context to worry about. Even if this is not the case, the #0 / #1 combination works brilliantly as a solution. (Use #1 within the poly~ patch; use #0 from the outside as the argument for #1)
(whoops, just saw Zach’s post. Pardon the double!)
Just as a follow-up in case folks are reading this later:
Re: what PID [me] said:
i made a confusion there. i was not referring to inclusive use inside a poly~, of course you can; i was referring to using send~/receive~ pairs from OUTside to INside a poly~, which is fraught with danger, but which in turn was my stupid misreading of the initial thread and ultimately irrelevant.