Forums > MaxMSP

local send/receive (within the same patch only)

October 14, 2011 | 2:11 pm

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?
Thanks!!


October 14, 2011 | 2:35 pm

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.

Cheers,
Tim


October 14, 2011 | 3:12 pm

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.


October 14, 2011 | 4:28 pm

If the send and receive are numbers, you could use [pvar] too, couldn’t you?


October 14, 2011 | 6:08 pm

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 :-)


October 14, 2011 | 7:30 pm

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.


October 14, 2011 | 7:48 pm

#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,
cheers
Roger


October 14, 2011 | 9:08 pm

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?


October 14, 2011 | 10:28 pm

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

– Pasted Max Patch, click to expand. –

October 15, 2011 | 6:23 pm

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


December 21, 2013 | 1:59 pm

If you want a named object to be unique to a device, use three dashes (—) to start the name of your buffer or send/receive destination. three dashes.


January 5, 2014 | 9:12 am

Thank you Omar. That is so useful and just works.


Viewing 12 posts - 1 through 12 (of 12 total)