local send/receive (within the same patch only)

Oct 14, 2011 at 2:11pm

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?

Oct 14, 2011 at 2:35pm

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.


Oct 14, 2011 at 3:12pm

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.

Oct 14, 2011 at 4:28pm

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

Oct 14, 2011 at 6:08pm

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

Oct 14, 2011 at 7:30pm

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.

Oct 14, 2011 at 7:48pm

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

Oct 14, 2011 at 9:08pm

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?

Oct 14, 2011 at 10:28pm

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. –
Oct 15, 2011 at 6:23pm

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

Dec 21, 2013 at 1:59pm

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.

Jan 5, 2014 at 9:12am

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


You must be logged in to reply to this topic.