Forums > MaxMSP

Keeping data local to subpatches

August 27, 2007 | 2:09 pm

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.

Here is the subpatch probabilitylist:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 1263 105 81 196617 first item in list;
#P number 1220 103 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 499 102 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 271 62 14 0;
#P newex 335 81 42 196617 pv vals;
#N comlet List of values (max of 10 items);
#P inlet 271 38 14 0;
#P button 997 62 15 0;
#P newex 1061 85 49 196617 pv probs;
#P message 1322 161 48 196617 set 9 $1;
#P message 1265 161 48 196617 set 8 $1;
#P message 1208 161 48 196617 set 7 $1;
#P message 1154 161 48 196617 set 6 $1;
#P message 1102 161 48 196617 set 5 $1;
#P message 568 162 58 196617 store 8 $1;
#P message 507 162 58 196617 store 7 $1;
#P message 446 162 58 196617 store 6 $1;
#P message 630 162 58 196617 store 9 $1;
#P message 385 162 58 196617 store 5 $1;
#P button 818 121 15 0;
#N comlet List of probabilities (percentages);
#P inlet 997 38 15 0;
#P outlet 303 358 15 0;
#P button 29 107 15 0;
#P message 258 163 58 196617 store 3 $1;
#P message 192 163 58 196617 store 2 $1;
#P message 124 164 58 196617 store 1 $1;
#P message 323 162 58 196617 store 4 $1;
#P message 58 163 58 196617 store 0 $1;
#N comlet bang to output value;
#P inlet 29 47 15 0;
#N coll nums 1;
#T flags 1 0;
#T 5 1;
#T 4 5;
#T 3 4;
#T 2 3;
#T 1 2;
#T 0 1;
#P newobj 303 319 61 196617 coll nums 1;
#P message 759 162 43 196617 size 10;
#P newex 719 134 48 196617 loadbang;
#N vtable 10 35 722 245 889 970000 100;
#P newobj 1080 291 58 196617 table;
#P message 1046 162 48 196617 set 4 $1;
#P message 989 162 48 196617 set 3 $1;
#P message 932 162 48 196617 set 2 $1;
#P message 878 162 48 196617 set 1 $1;
#P message 826 162 48 196617 set 0 $1;
#P newex 1061 105 131 196617 unpack 1 1 1 1 1 1 1 1 1 1;
#P newex 335 103 131 196617 unpack 1 1 1 1 1 1 1 1 1 1;
#P comment 1024 38 100 196617 probabilities;
#P window linecount 2;
#P comment 49 68 100 196617 bang to output number;
#P comment 945 381 371 196617 given a list of at most 10 ints and 10 probabilities it outputs these numbers according to the specified distribution in response to a bang;
#P window linecount 1;
#P comment 300 38 34 196617 values;
#P comment 542 100 81 196617 first item in list;
#P connect 6 9 35 0;
#P connect 6 8 34 0;
#P connect 36 0 6 0;
#P connect 36 0 42 0;
#P connect 6 7 33 0;
#P connect 6 6 32 0;
#P connect 6 5 31 0;
#P connect 35 0 12 0;
#P connect 34 0 12 0;
#P connect 33 0 12 0;
#P connect 32 0 12 0;
#P connect 31 0 12 0;
#P connect 7 0 12 0;
#P connect 9 0 12 0;
#P connect 11 0 12 0;
#P connect 14 0 12 0;
#P fasten 22 0 12 0 34 228 1085 228;
#P connect 8 0 12 0;
#P connect 10 0 12 0;
#P fasten 37 0 36 0 1002 81 1066 81;
#P connect 24 0 25 0;
#P connect 24 0 37 0;
#P fasten 24 0 36 0 1002 58 1066 58;
#P connect 6 4 11 0;
#P connect 6 3 10 0;
#P connect 6 2 9 0;
#P connect 6 1 8 0;
#P connect 6 0 7 0;
#P connect 13 0 14 0;
#P connect 25 0 14 0;
#P connect 5 9 27 0;
#P connect 5 8 30 0;
#P connect 5 7 29 0;
#P connect 39 0 5 0;
#P connect 39 0 41 0;
#P connect 5 6 28 0;
#P connect 5 5 26 0;
#P fasten 40 0 39 0 276 78 340 78;
#P connect 38 0 40 0;
#P fasten 38 0 39 0 276 57 340 57;
#P connect 5 4 18 0;
#P connect 15 0 23 0;
#P connect 27 0 15 0;
#P connect 30 0 15 0;
#P connect 29 0 15 0;
#P connect 28 0 15 0;
#P connect 26 0 15 0;
#P fasten 12 0 15 0 1085 317 308 317;
#P connect 17 0 15 0;
#P connect 19 0 15 0;
#P connect 20 0 15 0;
#P connect 21 0 15 0;
#P connect 18 0 15 0;
#P connect 5 3 21 0;
#P connect 5 2 20 0;
#P connect 5 1 19 0;
#P connect 5 0 17 0;
#P connect 16 0 22 0;
#P window clipboard copycount 44;

and a test patch:

#P button 194 94 15 0;
#P window setfont "Sans Serif" 9.;
#P number 51 241 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 397 247 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 51 206 74 196617 probabilitylist;
#P newex 397 211 74 196617 probabilitylist;
#P button 509 96 15 0;
#P newex 439 97 48 196617 loadbang;
#P message 479 125 91 196617 30 25 15 5 15 20;
#P message 394 131 73 196617 64 32 8 4 2 1;
#P newex 126 92 48 196617 loadbang;
#P message 129 122 70 196617 55 30 10 2 2;
#P message 73 122 52 196617 1 2 3 4 5;
#P toggle 248 37 15 0;
#P newex 246 60 58 196617 metro 100;
#P connect 2 0 10 1;
#P connect 3 0 10 2;
#P connect 10 0 12 0;
#P fasten 0 0 10 0 251 197 56 197;
#P fasten 0 0 9 0 251 197 402 197;
#P connect 6 0 9 2;
#P connect 5 0 9 1;
#P connect 9 0 11 0;
#P connect 13 0 2 0;
#P connect 13 0 3 0;
#P connect 8 0 5 0;
#P connect 8 0 6 0;
#P connect 7 0 5 0;
#P connect 7 0 6 0;
#P connect 4 0 2 0;
#P connect 4 0 3 0;
#P connect 1 0 0 0;
#P window clipboard copycount 14;

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.


August 27, 2007 | 9:33 pm

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.


August 28, 2007 | 6:40 am

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


August 28, 2007 | 4:24 pm

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.

Thanks!


August 28, 2007 | 5:29 pm


August 28, 2007 | 5:44 pm


August 28, 2007 | 7:16 pm

greetings,

> 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.

> Thanks,
> ej

- thanks for the quick reply and help thereafter.

peace,

_z


August 28, 2007 | 8:31 pm


August 29, 2007 | 8:16 pm

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

coll #1_my_coll

…no spaces.

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.

–CJ


August 29, 2007 | 8:26 pm

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

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.

also look at pvar.

-rob


August 29, 2007 | 8:44 pm

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.

I hope this makes sense. :()

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


Viewing 11 posts - 1 through 11 (of 11 total)