digiology

Hi, I have two instances of a subpatch in which I can seperate data to but want to ensure they maintain their own local data. In particular the table and coll objects seem to share the same data as a result of the data coming in the inlets.

The subpatch basically takes in a list of values and a list of probabilites (well, percentages) that they will be outputted in response to a bang. Im sure there are easier ways to implement this (do share!), its mainly a convenience thing for me.

As you can see the pv object does a good job for storing the incoming data locally but the table and coll object still share data between instances of probability list.

keeping-data-local-to-subpatches-2

In Max, basically everything is global. That makes for a simple model, but it has it's limitations, as you are discovering.

Your best bet for getting independent tables & colls in abstractions is to use the #0 trick. This has been discussed on the list several times and is documented nicely somewhere in the examples. Sorry not to be able to name the exact example.

or in other words, when you dont want to share coll data, just dont name the colls. :)

ok cool, that makes sense. Im guessing the #0 trick allows you to give coll a name via a typed in argument to the sub-patch or something... never heard of that before but seems like it would work.

> message is the message box object. So you're sending jit_matrix to a

- it took me a while but a stray cable indeed landed on a pict msg box.

thanks for pointing me in the right direction.

> It's recommended to start a new thread by sending a new mail instead

- agreed - it was my intention / apologies.

- thanks for the quick reply and help thereafter.

> message is the message box object. So you're sending jit_matrix to a
> message box. Can you post a patch?

 - it took me a while but a stray cable indeed landed on a pict msg box.
thanks for pointing me in the right direction.

> It's recommended to start a new thread by sending a new mail instead
> of replying.
- agreed - it was my intention / apologies.

I think you need to use the #1 or #2 etc. in an actual bpatcher, not a subpatch, but I may be wrong. Just use #1 wherever you need a changeable argument when the bpatch is used. Be sure to put it at the *front* of your coll names, like

Then Get Info... on the bpatch will let you set the argument list (only one element in this case). Or, if not a bpatch, just type in the argument list in the object itself.

If you're using subpatches I don't know how this works. Then you can just name each instance of the coll something else (or not name it, as mentioned). If the subpatches are going to be the same except for the argument, you should be using bpatches / objects instead.

#0 is replaced by a dynamically created number, created at runtime, specific to that patch.

first patch has "send #0_foo" and "receive #0_foo"

these will get the same argument, and hence, pass messages to each other.

they will talk to each other, and not the first patch.

can't remember how this functions in sub-patches. try it and see.

if my memory serves me correct:
first patch has "send #0_foo" and "receive #0_foo"
these will get the same argument, and hence, pass messages to each other.

a second patch has the same thing: 
"send #0_foo" and "receive #0_foo".
they will talk to each other, and not the first patch.
works for colls as well.

works great for abstraction instances.
can't remember how this functions in sub-patches. try it and see.

If you use an #0 argument in a sub-patch (not a saved abstraction, but in a patcher [p] object) it will keep the same argument number as the parent patch.

However, an abstraction loaded into your patch using #0 will (of course) have a unique number different from one in the parent patch.

refer to the 'Arguments: $ and #, Changeable Arguments to Objects' 

section towards the end of the max tutorials/topics

If you use an #0 argument in a sub-patch (not a saved abstraction, but in a patcher [p] object) it will keep the same argument number as the parent patch. 

However, an abstraction loaded into your patch using #0 will (of course) have a unique number different from one in the parent patch. 

refer to the 'Arguments: $ and #, Changeable Arguments to Objects' 
section towards the end of the max tutorials/topics


Keeping data local to subpatches