Best Practice for Unique Instantiation of M4L Patches?
Posted: Tue Jan 26, 2010 3:53 pm
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?
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?