local send/receive (within the same patch only)
Hi all – I’m getting so much out of the forum, it’s great.
This should be a simple one. To avoid making 18 connections from one box to 18 others, I want to use send / receive. But its only within this patch, so if possible I’d like communication to stay ‘local’
Not sure if there is a performance advantage, but one benefit of the names only being valid locally would be that I could use the same send/receive naming in other patches at the same time.
I read about the "—" in front of the buffer name, but I"m not getting it.
When I do ‘send —local’ I can still receive the message with a ‘receive —local’ in other patches, or even in other max for live patches on different tracks.
Am I misunderstanding how I should use "—" or is this just not what it is for?
If you begin the names with #0 ( e.g. [send #0foo] and [r #0foo] ) then it will be local to the abstraction that contains it.
The local names with (—) are a specific feature of M4L and have no effect in Max.
If you open an M4L device in the editor, it’s actually running in Max and thus the names are *not* local.
Only when the device is running in Live (ie. not in editor mode) the local names are effective.
If the send and receive are numbers, you could use [pvar] too, couldn’t you?
Broc, thanks – that makes sense!
Tim – I’m still not getting it: I have 2 patchers, opened in windows side by side and I can send to #0path in the other window without problems..
Pvar.. No idea :-)
Regarding [pvar]: it can be used in Max and M4L for local "wireless" communication. But in contrast to send/receive with (—) names the receiver must be a named object. So I think it’s less flexible.
#0 works when you save a patch as an abstraction, in that the #0 is turned into a number unique to that instance of the abstraction as it is created.
So if you save a patch with a [send/receive #0foo] in it, it will initialise as say [send/receive 8677foo] in one instance of the abstraction, and [send/receive 7923foo] in another, and thus be local to each instance.
When you’re editing it as a patch, however, it will still just be [send/receive #0foo] in every instance, and thus be global,
Thanks Roger! That is actually extremely useful – I may end up using that a lot. Sounds like there could be trouble wwhen you have 2 abstractions open for editing at the dame time though
Any ideas in terms of performance whether I should minimise send / receive pairs?
Probably you won’t have issues with 2 abstractions open, in most cases it’s just one abstraction and you’re using multiple instances in your patch. Your original question may have been about subpatches, which aren’t abstractions, they’re part of the main patch. So the #0 won’t work in them. Instead, look to [patcherargs] for subpatches, you can use them to make indexed lists for your values and then use [sel] to differentiate.
…though this is actually more work than just renaming your send and receives :)
…still, patcherargs can be useful
----------begin_max5_patcher---------- 1752.3oc6b9siahCEF+5To9NXEsWlMByeBjd29bTsZDI3j3sDbD3jNcq1280 XSx.YIoLSwkvreyEgQXvX+4iOGa7O72+3GlLck3YVwTxmHelLYx2UmYh9bkm Yx4SLY593mWmFWnuvoqE62yxjSmUknj8rTmv9iERRpHNYUb1VBOqfmvHEGWc HVtdGqfHEj30R9oXIiXNWdb91hKYzFQlLKdOSmY+QNON8RRYG2yyRYRcIfd9 r7D8kJV8W+N0o90JNJOewN0y8B9eqycp67KmWWR3YaeJmsVZTB2n.U5DOG8u 99y8bbbnQyHtpyP9S8M9Oe7CkGUGl0YkKi8UUY8+JbGHKU+8p0AmVzgkcQF1 Dul0PHanMQcQaBM+5MOTIMNAJoIrTZZbir7Jw3rZndP7T1IVdAWjUu.LY5KO fvkZY2cwxxC9dt5CN90xdkPuMUr9Krj5UsISSXadk4i3.K6kaQeCM94pKkmc HmUnL9ikU0fFO73ioxmtgcVyK3bKP6o1di+joay4IhrxBRy6s77mejelP0MM k+Vqzqujr3Csc6RgHcUb9IdAeUJqY6hxhNNiuW0kUxMEJWmWtS99C47LYyri kEqxlcEqyEooMyMSRmZKoD1I9Z1W4Ixc5rqlv0vGUcyoF83Zlv88Y0r62o3z iJ2SaEZOToojMBAQYUv3mXEyHqNJIhrzuQj6Xjb91cRkusD1yjuxUW6Vlr71 JSakPJE6a7LR4Yr0hiFIxqdJ2oc9lN7ttyt6hqumV5weOme2rStq1FxMHTaJ szzEJ5hyuIu3.r5em8laZ1yJJh2xZuoozunp.GM8sJct2R5BtizQ6pzYtG42 NT00a5zW5xcSo0WKsd5CTmn4tkURkGTpcz26Z5WKLLQ2MXZuai5aMaTOcHnE 0LQqEe9WlDlIjrOQJTxDQqU8t.5Y4N4TmAVAMdS2HxIpPqIpBY+qgtVSCq5F OzZntyaYfnRIr+0OpszOpmwa3.KeERQNy3AbNguoJ.updthkSDaJUU0Ta3p4 2r+7jY1wxHlI5nFdvQ4sC6616sFN10Z1iVOrumuUZNZNWnqbHz6g6oQVIbud ru+nH9zPipZb25ELOLvZF42SUOlcHd8WHNDmd2+.M7Nxq6Ok7NqqprO03Iwq Z5oKKmXpq0T56Nr0B0jB9MZ+aEuXfFzJ0Y4KS52OzLj0kVaHqF+t8uUZfMsR KiEzgg+qMOizCZMvwhg6rkF5O7Z3YGpgt1WEui+zBVZ+2C20JxqVWm0od5Fs 0MZ4vFrJu7kv7lkWmaIuzgxAZUzIG8Hq7hlGLLAlr16Sg5LruOEpWzun2mx8 rZOjyNXi4eMXw8CnFUUeXgy7gwYv40Tp20U67R.63HALNZMJ6hAJFVKKCWuI t1YjBcKLlQb80Awhny8s6bArzXs7d.FpkwAfa3vNRqepACbygxZo2hxYmldK Lq3nYIRo+.kq1Z0U91it05coedkWvMzzBww70mapqbwQbZ1NmvJj7rKKg4mu zc85KbGOI4pEKT2twSNHTlQUkwWiwvqt3620hOMXjW9Ui7mPeKkeZTjIRB80 0w7UWWJG8bGqLgOjMF5hEsSUfn2Zqg8q.c2b5ArEvsyUfnGyJPTmq.icGpKd HK+K5b4ejW7cdH8.400x+io0CcwHu724Pvk.tzy1OmSnrtTw4WQ7IVxSpmmZ zuOEKk47UGklAu1f6u6y918XdqKbw8CQu61O1Vu7sohUwoUyM9xCc5kZuE.. MzuWv+Lx53eZnEwrRPpI5bYtM8E9mAFvnbMuRj2N9mcJe.9m.+Sf+Iv+D3eB 7OA9m.+Sf+Iv+D3eB7OA9m.+Sf+Iv+D3eB7OA9m.+y2K3eF5Sh7.6mf8Sv9I X+DreB1OA6mumY+bPoE.3ZL5okYrCqzHmUrwNpdidVIG+zpN54EdzSr8XmY9 2Se.Ci8OljA7a4AreZO1OWzOa8mg1l8SpWfcY+rB3L2H5OG6mcJe.6mf8Sv9 IX+DreB1OA6mf8Sv9IX+DreB1OA6mf8Sv9IX+DreB1OA6mf8y2KreFDn7Y6B 3OA7m.9S.+If+DveB3OmfM9SrweBtYlfM9SrweBTJwF+I13OAK8uO+TFvF+I f+b.g+7pUft1JyUvpVq4BMFDsLu7NCEJsEnP85BTnsnEsM+FeypXZ3cHxwL4 5kMldS+BFaPPu.FK01fwtn9dhp+44M2KHw54zK6FpcIa.Pr.HV.DK.hE.wBf XAPr.HV.DK.hE.wBfXAPr.HV.DK.hE.wBfXAPr.HV.DK.hE.wBfXAPr.HV.D K.hcr.DK1MTABQX2PE6Fp.fz+uhvK1MTwtgJ9pNvtgJ.h0R.wVpKpC+qYo40 1 -----------end_max5_patcher-----------
I think making — work in max standalone would be great… it should be local the whole patcher hierarchy, only differentiated by seperate top-patchers… Feature request
Thank you Omar. That is so useful and just works.