Best Practice for Unique Instantiation of M4L Patches?

[mastahlee]

This question might be better suited for the Cycling '74 forums, but it deals specifically with problems with my M4L patches, so I'll throw it out here as well.

In my patches, I like to use a lot of send and receive objects as well as named coll objects to help make an easy-to-read workflow. However, I noticed that a "feature" of Max is causing me great pains: when you have multiple instances of a patch the named objects are globally accessible. To put it more plainly, when I input some data into a send object in one of my patches, it is received in EVERY receive object in ALL INSTANCES I have of that patch, whereas what I really wanted was for the data to be received ONLY in the receive objects IN ITS OWN INSTANCE of the patch.

Say I have a patch that observes the playing clip index on a track, sends the index through a send object called "index_number" that is then received by an "index_number" receive object somewhere else in the patch that does some logic with it. I have it working and everything is good. I decide I want to put an instance of this patch on 3 of my tracks in Live, because I want to observe playing clip changes on three tracks INDEPENDENTLY. Now I have a problem. Whenever ANY of those tracks has its playing clip changed, the "index_number" receive objects ON ALL 3 INSTANCES OF THE PATCH receive that index number and perform logic on it, which completely screws everything up.

My current workaround has been to create a different patch for each instance of it that I want to use. So I'll have the "Track Watcher" patch, as well as "Track Watcher 2" and "Track Watcher 3" with the only difference between them is the send and receive objects are named "index_number", "index_number_2" and "index_number_3" respectively. This is highly obnoxious, cumbersome to maintain, and I'm sure there must be a better way to do this without completely throwing away the utility of send and receive objects.

My question is: Is there a proper way to name variables that limits its scope to just that instance of the patch? In effect I want to be able to make my M4L patches completely self-contained instantiations, so if use the patch in multiple places within my live set its variables won't be globally accessible and clashing with one another. Anyone have some insight on this?

[technog0d]

send ---name and receive ---name sounds like what you are looking for. The three dashes make the name unique to your current patch. So, just add three dashes to the name of the coll.

I hope this helps.

[mastahlee]

send ---name and receive ---name sounds like what you are looking for. The three dashes make the name unique to your current patch. So, just add three dashes to the name of the coll.

I hope this helps.

Great, thanks for the quick reply! I'll have to try this out when I get home from work. Out of curiosity, where did you run across this piece of information? Google, forum, and documentation searches have all be fruitless for me on this one.

[hyaahyaa]

For some reason the documentation page that explains this isn't online, but it's a "vignette" called "Live Symbols" or "Using Symbols in Max for Live" and should be on your hard drive.

[technog0d]

It's in the documentation somewhere. They did it a little bit differently in Max then in M4L. So, some people do not realize this. I am glad I can be of help. I really like what you are doing with the Ms Pinky stuff. I hope to contribute soon.

Mike

[mastahlee]

It's in the documentation somewhere. They did it a little bit differently in Max then in M4L. So, some people do not realize this. I am glad I can be of help. I really like what you are doing with the Ms Pinky stuff. I hope to contribute soon.

Mike

Ha, you already contributed. Now the next version of Ms. Pinky won't blow up if you have more than one instance of it

[mastahlee]

For some reason the documentation page that explains this isn't online, but it's a "vignette" called "Live Symbols" or "Using Symbols in Max for Live" and should be on your hard drive.

Yeah, I searched through the online documentation, which is apparently not complete. That's pretty annoying, as I lean somewhat heavily on the online docs for figuring stuff out when I'm not at my production machine. Oh well, thanks for letting me know where it is.