David Stanford

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 

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?

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?

funnel-bug

System info was omitted from my previous post, apologies:

Asking if its a bug or your brain is dangerous, because in this case its 

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

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

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         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


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 

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.

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.

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.

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 

most recently received a value of one. So if you turn on the [led] 

connected to inlet 4 of [funnel] you'll see:

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 

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.

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!

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

[funnel] bug?