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.


October 20, 2014 | 3:26 am

Hi all,

Here is a tricky one. I have patch as an abstraction(lets call it A) and I am using #0 so as to make several unique copies of it. Inside this patch I have a pfft subpatch(let’s call it B). Inside B there is there is a send object. The receive object is in abstraction patch A .

So although I use #0 for the send/receive objects, Max gives to them a different numbers as long as the first is in the subpatch(B) and the second one is in A. The result is that there is no connection between A and B . Any help?

I suppose the problem is that #0 works strictly inside patches and it’s not possible to have a trade-off between them.Is it possible to create an extra outlet on pfft so as there is no need of receive/send?

  • This reply was modified 1 day by  seabed.


Jan
October 20, 2014 | 4:38 am

you can pass #0 as an argument to your abstraction and use #1 inside.
j


October 20, 2014 | 4:59 am

Hey Jan, can you please explain that a bit more?

Btw, I am now using no-fft argument at outlet 2 of pfft, so as to skip the use of send/receive.



Jan
October 20, 2014 | 6:09 am

What I mean is initiating your abstraction with [myAbstraction #0] and use [send #1_mySendName] inside. But wait… was working to too much on M4L these days. #0 does not work inside the top level patcher. In M4L you can do that with "—".

For Max you’ll can create a random id on load and set forward/receive objects with this id prepended. I use some abstractions for that:

main patch:

– Pasted Max Patch, click to expand. –

jm.sendReceive:

– Pasted Max Patch, click to expand. –

jm.localSend

– Pasted Max Patch, click to expand. –

jm.localReceive:

– Pasted Max Patch, click to expand. –

Maybe someone has a slicker solution :)

J


October 20, 2014 | 9:43 am

Thx I will check it out.


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