Unexpected grab behavior


    Jul 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.
    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
    --
    ----- |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| -----

    • Jul 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.
      -------------- 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|
    • Jul 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
      >
      >
      >
      --
      ----- |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| -----
    • Jul 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
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Jul 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
      >
      >
      --
      ----- |(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)| -----