local send/receive (within the same patch only)

    Oct 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!!

    • Oct 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
    • Oct 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.
    • Oct 14 2011 | 4:28 pm
      If the send and receive are numbers, you could use [pvar] too, couldn't you?
    • Oct 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 :-)
    • Oct 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.
    • Oct 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
    • Oct 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?
    • Oct 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
    • Oct 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
    • Dec 21 2013 | 9: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.
    • Jan 05 2014 | 5:12 pm
      Thank you Omar. That is so useful and just works.
    • Oct 20 2014 | 10: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?
    • Oct 20 2014 | 11:38 am
      you can pass #0 as an argument to your abstraction and use #1 inside. j
    • Oct 20 2014 | 11: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.
    • Oct 20 2014 | 1:09 pm
      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:
      Maybe someone has a slicker solution :)
    • Oct 20 2014 | 4:43 pm
      Thx I will check it out.