send/receive local to patcher

May 16, 2011 at 11:38pm

send/receive local to patcher

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.

#57169
May 17, 2011 at 1:12am

Does something like this work? You would need to have [receive~] objects in the main patch for each of your [poly~] instances.

– Pasted Max Patch, click to expand. –
#204796
May 17, 2011 at 6:25am

I recall posting these three characters to a thread before… pv?

#204797
May 17, 2011 at 6:52am

My preferred mechanism for passing messages locally and privately within a patch? “They call them ‘patch cords’.”

#204798
May 17, 2011 at 7:01am

Mine too, but I thought the OP was talking about passing specific signals from poly~ subpatchers out to the main patcher.

#204799
May 17, 2011 at 8:33am

you cannot use send/~ receive/~ inside a poly~. period.

this is what i do:

– Pasted Max Patch, click to expand. –
#204800
May 17, 2011 at 9:20am

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.

#204801
May 17, 2011 at 9:30am

hey rtech, did you check out
http://cycling74.com/toolbox/kneppers-oo-objects/
?

#204802
May 17, 2011 at 4:07pm

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.

#204803
May 17, 2011 at 4:30pm

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.

#204804
May 17, 2011 at 4:55pm

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.

http://cycling74.com/forums/topic.php?id=17714

best,
Zachary

#204805
May 17, 2011 at 4:58pm

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!

#204806
May 17, 2011 at 5:19pm

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.

Attachments:
  1. receiverdemo.zip
#204807
May 31, 2011 at 6:58pm

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

#204808
May 31, 2011 at 10:41pm

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.

#204809

You must be logged in to reply to this topic.