[funnel] bug?


    Mar 11 2006 | 12:05 am
    Summary: Under certain circumstances, [funnel] doesn't correctly report
    the inlet number when the lowest numbered inlet receives a number.
    Steps To Reproduce: See patch below - Click on any [led] other than the
    leftmost in the top tier, and notice that the corresponding [led] in
    the second tier does not light up. Check out the messages in the Max
    window to verify that [funnel] isn't correctly mapping its input.
    Expected result: When a number is received by inlet 0, the outlet
    reports that a number was received by inlet 0.
    Actual result: When a number is received by inlet 0, the outlet reports
    a message received in another inlet.
    Discussion: I see that inserting [deferlow] into the patch is a viable
    workaround, and normally I would think that I am simply missing
    something about message order, however, I just can't figure out where
    [funnel] is pulling the wrong info from. Can anybody tell me if this is
    a bug or if it's a problem with my brain?
    Thanks,
    David
    max v2;

    • Mar 11 2006 | 12:18 am
      System info was omitted from my previous post, apologies:
      MaxMSP 4.5.7, Jitter1.5.2, OSX.3.9
    • Mar 15 2006 | 8:58 pm
      Asking if its a bug or your brain is dangerous, because in this case its
      not a bug...;-)
      In general, if deferlow fixes it, the bug is in the patch, not in the
      objects. Try trace to figure out whats going on. Beside that I think
      there are easier solutions as you might expect...
      Look at the patch below for a completely different approach...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • Mar 15 2006 | 9:26 pm
      Stefan - Thanks so much for your reply.
      Yeah - trace is where I'm having issues figuring out what's wrong. When
      I run a trace everything happens as I expect it, until [funnel]
      receives a "0" message passed through [led] from the leftmost outlet of
      [spray]. What happens then is that [funnel] seems to mis-report which
      inlet has just received a message - it substitutes the last inlet that
      received a "1" message. Did you run this patch through a trace? If you
      did, could you tell me *exactly* where the problem is? If you didn't, I
      would greatly appreciate it if you could. I just can't wrap my head
      around how jumbled message order would cause an object to report a
      message that it has never, ever received.
      I realize that there are many, many easier, and much more efficient
      ways to do this: jasch's [mtx], [matrixctrl], and many others . I came
      this convoluted (but, I think legal) solution as one of 6 that I
      thought of as an exercise in trying to find as many ways as I could
      think of to accomplish a single task. My interest is not in
      accomplishing the task that this patch seems to be attempting to
      accomplish, but rather to figure out what my brain isn't seeing about
      the message order with the patch itself. I would appreciate your help
      in that department greatly.
      -David
    • Mar 16 2006 | 7:29 pm
      Well, I didn't, but looking at the patch with the fact that a deferlow
      creates the expected result, I just assume its because the order of
      execution is changed. You might have overwritten something in the mean time.
      You don't even need trace to find out, your patch prints all the
      information in the Max window. You don't see the corresponding LED
      because after you switch it on, you switch it off again. Too short to
      see it. Deferlow just moves the on switch to the end of the execution queue.
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • Mar 16 2006 | 9:31 pm
      Yes, I'm aware that it's switched on and then off again ;)
      Here's the issue: If you look carefully at the messages that print,
      you'll see that at some point [pack] passes "0 0" to [spray] which
      passes a "0" through an [led] to inlet 0 of [funnel]. The very next
      message that is passed is "n 0" from funnel, where n = whichever
      [funnel] inlet
      most recently received a value of one. So if you turn on the [led]
      connected to inlet 4 of [funnel] you'll see:
      funnel: 4 1
      pack: 5 0
      funnel: 5 0
      pack: 0 0
      funnel: 4 0
      pack: 1 0
      funnel: 1 0
      pack: 2 0
      funnel: 2 0
      pack: 3 0
      funnel: 3 0
      Hey! Where'd that "4 0" message come from? The last perceivable message
      that was sent to [funnel] was "0" to inlet 0, which should've resulted
      in "0 0" being reported, but didn't!
      with [deferlow], this becomes:
      funnel: 4 1
      pack: 5 0
      funnel: 5 0
      pack: 0 0
      funnel: 0 0
      pack: 1 0
      funnel: 1 0
      pack: 2 0
      funnel: 2 0
      pack: 3 0
      funnel: 3 0
      So happy, but still puzzled why this fixes it...
      So - it's not just a matter of the "switch on" message being moved to
      the end. The "0 0" message that is passed to inlet 0 of [funnel] is
      changed in substance, not order. Note that the "4 0" message doesn't
      appear *anywhere* in the [deferlow] version. So - order of execution
      certainly is changing, but it's not changing in a place that you can
      see in the workings of the patch, not by trace or any other method I
      know of (seriously - try it! :)). The only way I can tell is by seeing
      the end result, which is what prompted the question in the first place.
      At any rate, I have an e-mail into c74 support about it.
      Thanks again,
      David