[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

    • 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