Ignotus

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

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

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.

----- |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| -----

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.

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.

-- 
-----   |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)|   -----


unexpected-grab-behavior

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

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 

In some ways I prefer your dual-coll solution, but it's nice to have 

Peter Castine +---> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

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

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.

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

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.

> 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

> 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

> In some ways I prefer your dual-coll solution, but it's nice to have

> #P newex 39 113 64 196617 print animal;

> #P newex 122 114 88 196617 t b i i clear;

> #P comment 38 55 66 196617 other solution;

> #P fasten 6 0 4 0 127 164 164 164 164 138 180 138;

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.

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

> 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 

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

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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

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

> #P newex 116 71 88 196617 t b i i clear;

> #P fasten 0 0 3 0 38 94 110 94 110 66 121 66;

> #P fasten 9 0 6 0 174 145 209 145 209 65 223 65;

> #P fasten 4 0 2 0 121 121 158 121 158 95 174 95;

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

Unexpected grab behavior