Forums > MaxMSP

Unexpected grab behavior

July 12, 2006 | 1:59 pm

I’m used to the notion that grab sends a message to an object out its
right inlet and reroutes the result of that message out its left
inlet. It seems that messages out the left inlet will also cause the
rerouting, even when there is an intervening chain of objects.

The "problem" patcher below attempts to get the length of a coll and
then output its elements in random order using urn. I suggest tracing
it rather than executing it directly. The problem occurs with other
objects besides coll–table, for example–so it’s releated to grab and
not to the object grab sends a message to.

The solution seems to be to use a duplicate object–one for the
message from grab, one for the output of the chain off grab’s left
outlet.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 175 140 30 196617 + 1;
#P newex 437 144 30 196617 + 1;
#P comment 301 71 66 196617 solution;
#P newex 486 116 50 196617 print dos;
#N coll stuff;
#T flags 1 0;
#T 1 monkey;
#T 2 rat;
#T 3 tiger;
#T 4 ox;
#P newobj 486 93 69 196617 coll stuff;
#P newex 301 118 50 196617 print uno;
#P newex 384 122 36 196617 uzi 16;
#P newex 384 93 88 196617 t b i i clear;
#P newex 437 121 35 196617 urn;
#P newex 384 68 30 196617 grab;
#P message 384 45 37 196617 length;
#B color 2;
#N coll stuff;
#T flags 1 0;
#T 1 monkey;
#T 2 rat;
#T 3 tiger;
#T 4 ox;
#P newobj 301 95 69 196617 coll stuff;
#P newex 39 113 64 196617 print animal;
#P newex 122 117 36 196617 uzi 16;
#P newex 122 88 88 196617 t b i i clear;
#P newex 175 116 35 196617 urn;
#P newex 122 63 30 196617 grab;
#P message 122 40 37 196617 length;
#B color 2;
#N coll stuff;
#T flags 1 0;
#T 1 monkey;
#T 2 rat;
#T 3 tiger;
#T 4 ox;
#P newobj 39 90 69 196617 coll stuff;
#P comment 37 64 66 196617 problem;
#P fasten 19 0 1 0 180 164 117 164 117 86 44 86;
#P connect 4 0 19 0;
#P connect 15 0 16 0;
#P connect 8 0 14 0;
#P connect 12 2 11 1;
#P connect 12 3 11 0;
#P fasten 13 0 11 0 389 143 426 143 426 117 442 117;
#P connect 12 1 13 1;
#P fasten 12 0 13 0 389 116 389 116;
#P connect 10 0 12 0;
#P connect 9 0 10 0;
#P fasten 10 1 8 0 409 88 306 88;
#P connect 11 0 18 0;
#P fasten 18 0 15 0 442 167 477 167 477 87 491 87;
#P fasten 3 1 1 0 147 83 44 83;
#P connect 1 0 7 0;
#P connect 2 0 3 0;
#P connect 3 0 5 0;
#P fasten 5 0 6 0 127 111 127 111;
#P connect 5 1 6 1;
#P fasten 6 0 4 0 127 138 164 138 164 112 180 112;
#P connect 5 3 4 0;
#P connect 5 2 4 1;
#P window clipboard copycount 20;

This feature doesn’t seem to be documented, and came as somthing of a
surprise. It’s probably back in the vastness of the forum archives
somewhere.

A message out grab’s left outlet can also go through an object chain
before reaching a target object, and the result will be reported at
grab’s left outlet. This is potentially useful.

– Paul


—– |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| —–


July 12, 2006 | 2:48 pm

On 12-Jul-2006, at 15:59, Paul Hertz wrote:

> The solution seems to be to use a duplicate object–one for the
> message from grab, one for the output of the chain off grab’s left
> outlet.

Alternate solution below.

It seems as if grab is not releasing the grabbed outlet until the
call chain triggered by the length message is completed. A delay of 0
milliseconds fixes that.

In some ways I prefer your dual-coll solution, but it’s nice to have
a choice.

– P.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 122 90 37 196617 pipe 0;
#B color 14;
#P newex 175 166 30 196617 + 1;
#P newex 39 113 64 196617 print animal;
#P newex 122 143 36 196617 uzi 16;
#P newex 122 114 88 196617 t b i i clear;
#P newex 175 142 35 196617 urn;
#P newex 122 61 30 196617 grab;
#P message 122 38 37 196617 length;
#B color 2;
#N coll stuff;
#T flags 1 0;
#T 1 monkey;
#T 2 rat;
#T 3 tiger;
#T 4 ox;
#P newobj 39 90 69 196617 coll stuff;
#P window linecount 2;
#P comment 38 55 66 196617 other solution;
#P connect 9 0 5 0;
#P connect 3 0 9 0;
#P connect 5 2 4 1;
#P connect 5 3 4 0;
#P fasten 6 0 4 0 127 164 164 164 164 138 180 138;
#P connect 5 1 6 1;
#P fasten 5 0 6 0 127 137 127 137;
#P connect 2 0 3 0;
#P connect 1 0 7 0;
#P fasten 3 1 1 0 147 83 44 83;
#P connect 4 0 8 0;
#P fasten 8 0 1 0 180 186 117 186 117 86 44 86;
#P window clipboard copycount 10;

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +—> Litter Power & Litter Bundle for Jitter
Heavy-Duty Mathematics for Everyday Use
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


July 12, 2006 | 3:42 pm

Aha! that’s interesting. I imagine a pipe anywhere in the processing
chain is going to have the same result-I would guess that it would.

I suspect I probably shouldn’t try to exploit this behavior of grab.

– Paul

On 7/12/06, Peter Castine

wrote:
> On 12-Jul-2006, at 15:59, Paul Hertz wrote:
>
> > The solution seems to be to use a duplicate object–one for the
> > message from grab, one for the output of the chain off grab’s left
> > outlet.
>
> Alternate solution below.
>
> It seems as if grab is not releasing the grabbed outlet until the
> call chain triggered by the length message is completed. A delay of 0
> milliseconds fixes that.
>
> In some ways I prefer your dual-coll solution, but it’s nice to have
> a choice.
>
> — P.
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 122 90 37 196617 pipe 0;
> #B color 14;
> #P newex 175 166 30 196617 + 1;
> #P newex 39 113 64 196617 print animal;
> #P newex 122 143 36 196617 uzi 16;
> #P newex 122 114 88 196617 t b i i clear;
> #P newex 175 142 35 196617 urn;
> #P newex 122 61 30 196617 grab;
> #P message 122 38 37 196617 length;
> #B color 2;
> #N coll stuff;
> #T flags 1 0;
> #T 1 monkey;
> #T 2 rat;
> #T 3 tiger;
> #T 4 ox;
> #P newobj 39 90 69 196617 coll stuff;
> #P window linecount 2;
> #P comment 38 55 66 196617 other solution;
> #P connect 9 0 5 0;
> #P connect 3 0 9 0;
> #P connect 5 2 4 1;
> #P connect 5 3 4 0;
> #P fasten 6 0 4 0 127 164 164 164 164 138 180 138;
> #P connect 5 1 6 1;
> #P fasten 5 0 6 0 127 137 127 137;
> #P connect 2 0 3 0;
> #P connect 1 0 7 0;
> #P fasten 3 1 1 0 147 83 44 83;
> #P connect 4 0 8 0;
> #P fasten 8 0 1 0 180 186 117 186 117 86 44 86;
> #P window clipboard copycount 10;
>
>
> ————– http://www.bek.no/~pcastine/Litter/ ————-
> Peter Castine +—> Litter Power & Litter Bundle for Jitter
> Heavy-Duty Mathematics for Everyday Use
> iCE: Sequencing, Recording &
> Interface Building for |home | chez nous|
> Max/MSP Extremely cool |bei uns | i nostri|
> http://www.dspaudio.com/ http://www.castine.de
>
>
>


—– |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| —–


July 21, 2006 | 9:46 am

Paul Hertz wrote:
> Aha! that’s interesting. I imagine a pipe anywhere in the processing
> chain is going to have the same result-I would guess that it would.

pipe for this purpose is a bad and expensive idea, deferlow is made for
this sort of stuff and does the trick as well…

There was a thread, showing that a lot of pipes do sacrifice scheduler
perfomance, as it has to keep track of multiple events in the pipeline.

deferlow will just place the event at the end of the queue which is what
you need there…

On the other hand, with a coll there is no need for grab, as its easy to
seperate analysis and ouputs with multiple colls.
My solution would look like the patch below…

Stefan

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 169 122 30 196617 + 1;
#P comment 87 40 66 196617 solution;
#P newex 218 94 50 196617 print dos;
#N coll stuff;
#T flags 1 0;
#T 1 monkey;
#T 2 rat;
#T 3 tiger;
#T 4 ox;
#P newobj 218 71 69 196617 coll stuff;
#P newex 33 96 50 196617 print uno;
#P newex 116 100 36 196617 uzi 16;
#P newex 116 71 88 196617 t b i i clear;
#P newex 169 99 35 196617 urn;
#P message 33 51 37 196617 length;
#B color 2;
#N coll stuff;
#T flags 1 0;
#T 1 monkey;
#T 2 rat;
#T 3 tiger;
#T 4 ox;
#P newobj 33 73 69 196617 coll stuff;
#P connect 0 0 5 0;
#P fasten 0 0 3 0 38 94 110 94 110 66 121 66;
#P connect 1 0 0 0;
#P fasten 9 0 6 0 174 145 209 145 209 65 223 65;
#P connect 2 0 9 0;
#P fasten 3 0 4 0 121 94 121 94;
#P connect 3 1 4 1;
#P fasten 4 0 2 0 121 121 158 121 158 95 174 95;
#P connect 3 3 2 0;
#P connect 3 2 2 1;
#P connect 6 0 7 0;
#P window clipboard copycount 10;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


July 22, 2006 | 2:21 pm

On 7/21/06, Stefan Tiedje wrote:

Good point. I started out with "grab" so I continued grabbing…

– Paul

> On the other hand, with a coll there is no need for grab, as its easy to
> seperate analysis and ouputs with multiple colls.
> My solution would look like the patch below…
>
> Stefan
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 169 122 30 196617 + 1;
> #P comment 87 40 66 196617 solution;
> #P newex 218 94 50 196617 print dos;
> #N coll stuff;
> #T flags 1 0;
> #T 1 monkey;
> #T 2 rat;
> #T 3 tiger;
> #T 4 ox;
> #P newobj 218 71 69 196617 coll stuff;
> #P newex 33 96 50 196617 print uno;
> #P newex 116 100 36 196617 uzi 16;
> #P newex 116 71 88 196617 t b i i clear;
> #P newex 169 99 35 196617 urn;
> #P message 33 51 37 196617 length;
> #B color 2;
> #N coll stuff;
> #T flags 1 0;
> #T 1 monkey;
> #T 2 rat;
> #T 3 tiger;
> #T 4 ox;
> #P newobj 33 73 69 196617 coll stuff;
> #P connect 0 0 5 0;
> #P fasten 0 0 3 0 38 94 110 94 110 66 121 66;
> #P connect 1 0 0 0;
> #P fasten 9 0 6 0 174 145 209 145 209 65 223 65;
> #P connect 2 0 9 0;
> #P fasten 3 0 4 0 121 94 121 94;
> #P connect 3 1 4 1;
> #P fasten 4 0 2 0 121 121 158 121 158 95 174 95;
> #P connect 3 3 2 0;
> #P connect 3 2 2 1;
> #P connect 6 0 7 0;
> #P window clipboard copycount 10;
>
>
> –
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>


—– |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| —–


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