send/receive local to patcher

    May 16 2011 | 11:38 pm
    Is it possible to create send/receive objects that are local to the subpatcher they are in? An example of this might be a subpatcher with multiple copies going on within a poly object. Or maybe just not wanting to worry about not using the name again elsewhere in the patch if when creating the original send/recieve, you know it will not be used outside of the subpatch.

    • May 17 2011 | 1:12 am
      Does something like this work? You would need to have [receive~] objects in the main patch for each of your [poly~] instances.
    • May 17 2011 | 6:25 am
      I recall posting these three characters to a thread before... pv?
    • May 17 2011 | 6:52 am
      My preferred mechanism for passing messages locally and privately within a patch? "They call them 'patch cords'."
    • May 17 2011 | 7:01 am
      Mine too, but I thought the OP was talking about passing specific signals from poly~ subpatchers out to the main patcher.
    • May 17 2011 | 8:33 am
      you cannot use send/~ receive/~ inside a poly~. period.
      this is what i do:
    • May 17 2011 | 9:20 am
      Thanks for letting me know about using patch cords, I hadn't got that far in the manual yet.
      And to everyone else, thanks for the help and examples.
      My reason for wanting to do this: a sub patcher is getting crowded and I'd like to avoid having patch cords running across the interface while I'm working. It's a situation where there is one clock source being sent to several destinations. It would make things a lot cleaner using a send and multiple receives. I'd like to be able to name this something generic like clock, and afterwards, not have to worry about using that same variable name somewhere else without it picking up the messages going on in this subpatch.
      I have a feeling the answer is no. I know I could get around this simply by adding a number to the variable name to make it unique. At the same time though, I think in alot of software languages, local and global variables are fundamental and commonplace. I'm just wondering if Max has this capability. So this question is philosophical just as much as it's practical.
    • May 17 2011 | 9:30 am
      hey rtech, did you check out ?
    • May 17 2011 | 4:07 pm
      My post above, while it may have sounded simply smart-*ss, was actually expressing my Max programming "philosophy"/practice. send/receive and send~/receive~ use a shared namespace and are best thought of, in my opinion, as global channels of communication, rather than simply as substitutes for patch cords. The original post sounded to me like something that was most appropriate to patch cords, not global transmission/reception.
      There are many ways to deal with the "patch cords are messy" problem: object positioning, segmented patch cords, hidden patch cords, color-coded patch cords, etc. Yes, one can use send/receive as a substitute, but it introduces some of the potential problems mentioned, such as indeterminate message ordering and conflicting use of shared names.
    • May 17 2011 | 4:30 pm
      I see send/recieve the same way, as global communication. And I always use as few as possible. It would be nice however to have the option to make them local at times... to use them in a different way. Could be as simple as an option in the inspector called "global/local". In certain situations, the solutions for "messy patch cords" really aren't that great.
    • May 17 2011 | 4:55 pm
      You _can_ use send~/receive~ inside poly~, although you may not want to. I tend to agree with many here that patch cords are best.
      Here's an example of dynamically assigning send~ names inside a poly~ to create variable-pass effects (Jitter and MSP) - passing signal or data from one instance of poly~ to the next. Other better ways to do this though, this is really only for example. Was posted here a few years ago, but the attachment is missing for some reason.
      best, Zachary
    • May 17 2011 | 4:58 pm
      One thing that's helpful is that you can double click a send object and it lists all the send and receive objects with that name. This way you can be sure that it is not being used.
      I've found that its good practice to always check as it helps to avoid potential problems as a patch grows.
      On the other hand, this could create problems when duplicating sub patches because the send/receives will have the same name. I remember coming across a solution to this where they will automatically be renamed. It was something like [send ###-01], I can not remember or find it right now.
      Hope this helps and good luck!
    • May 17 2011 | 5:19 pm
      Here's a demo of something you might find useful. #0 in an abstraction gets replaced by a "unique" four-digit integer, and of course #1 in an abstraction gets replaced by the first typed-in argument.
    • May 31 2011 | 6:58 pm
      Just as a follow-up in case folks are reading this later: Re: what PID said:
      You absolutely _CAN_ use send~/receive~ within a poly~ (unless there's been a major undocumented change in the API!), and there are several valid reasons to do so. For example, I use it to do dynamic signal routing in situations where a full-on matrix mixer is overkill (or I am dynamically loading processing patches and need my mixing matrix to grow or shrink)
      That said, it's probably not the preferred solution, but it is legal and there are times when it is the best solution. It's particularly handy in patches (e.g. Max4Live) where you know there cannot be a global context to worry about. Even if this is not the case, the #0 / #1 combination works brilliantly as a solution. (Use #1 within the poly~ patch; use #0 from the outside as the argument for #1)
      (whoops, just saw Zach's post. Pardon the double!)
    • May 31 2011 | 10:41 pm
      Just as a follow-up in case folks are reading this later: Re: what PID [me] said: i made a confusion there. i was not referring to inclusive use inside a poly~, of course you can; i was referring to using send~/receive~ pairs from OUTside to INside a poly~, which is fraught with danger, but which in turn was my stupid misreading of the initial thread and ultimately irrelevant. apologies.