Cycling 74 » Topic: [funnel] bug?

[funnel] bug?

David Stanford — Sat, 11 Mar 2006 00:05:46 +0000

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;
#N vpatcher 44 52 489 384;
#P window setfont “Sans Serif” 9.;
#P window linecount 2;
#P comment 84 203 100 196617 unless deferlow saves the day.;
#P window linecount 3;
#P comment 232 133 100 196617 the corresponding led here will not lght
up…;
#P window linecount 1;
#P newex 33 299 55 196617 print pack;
#P newex 223 111 62 196617 print funnel;
#P newex 122 111 79 196617 spray 6;
#P user led 212 136 17 17 0 150;
#P user led 194 136 17 17 0 150;
#P user led 176 136 17 17 0 150;
#P user led 158 136 17 17 0 150;
#P user led 140 136 17 17 0 150;
#P user led 122 136 17 17 0 150;
#P user gswitch2 4 172 39 32 0 0;
#P newex 33 208 50 196617 deferlow;
#P newex 3 30 79 196617 spray 6;
#P newex 33 270 30 196617 pack;
#P newex 3 131 22 196617 b 1;
#P newex 33 231 27 196617 +;
#P newex 33 251 27 196617 % 6;
#P newex 3 150 40 196617 uzi 5;
#P newex 3 110 99 196617 if $i2 == 1 then $i1;
#P newex 3 82 79 196617 funnel 6;
#P user led 93 55 17 17 0 150;
#P user led 75 55 17 17 0 150;
#P user led 57 55 17 17 0 150;
#P user led 39 55 17 17 0 150;
#P user led 21 55 17 17 0 150;
#P user led 3 55 17 17 0 150;
#P window linecount 3;
#P comment 117 49 100 196617 Click on any of these , other than the
leftmost and…;
#P fasten 13 0 14 0 38 293 111 293 111 26 8 26;
#P connect 14 0 1 0;
#P connect 1 0 7 0;
#P connect 7 0 8 0;
#P connect 8 0 12 0;
#P connect 12 0 9 0;
#P connect 2 0 7 1;
#P connect 14 1 2 0;
#P connect 3 0 7 2;
#P connect 9 2 16 1;
#P connect 16 1 15 0;
#P fasten 16 0 11 0 9 228 38 228;
#P connect 15 0 11 0;
#P connect 11 0 10 0;
#P connect 10 0 13 0;
#P connect 13 0 25 0;
#P connect 14 2 3 0;
#P connect 4 0 7 3;
#P fasten 8 0 11 1 8 129 55 129;
#P connect 5 0 7 4;
#P connect 14 3 4 0;
#P connect 6 0 7 5;
#P connect 14 4 5 0;
#P connect 14 5 6 0;
#P fasten 7 0 23 0 8 104 127 104;
#P connect 23 0 17 0;
#P connect 23 1 18 0;
#P connect 23 2 19 0;
#P connect 23 3 20 0;
#P connect 23 4 21 0;
#P connect 23 5 22 0;
#P fasten 7 0 24 0 8 104 228 104;
#P pop;

Re: [funnel] bug?

David Stanford — Sat, 11 Mar 2006 00:18:25 +0000

System info was omitted from my previous post, apologies:

MaxMSP 4.5.7, Jitter1.5.2, OSX.3.9

Re: [funnel] bug?

Stefan Tiedje — Wed, 15 Mar 2006 20:58:08 +0000

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

#P user led 240 67 17 17 0 150;
#P user led 222 67 17 17 0 150;
#P user led 204 67 17 17 0 150;
#P user led 186 67 17 17 0 150;
#P user led 168 67 17 17 0 150;
#P user led 150 67 17 17 0 150;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N vpatcher 10 59 610 459;
#P outlet 543 150 15 0;
#P outlet 499 150 15 0;
#P outlet 455 150 15 0;
#P outlet 411 150 15 0;
#P outlet 367 150 15 0;
#P outlet 323 150 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 270 84 42 196617 == 5;
#P window linecount 2;
#P newex 270 114 42 196617 prepend set;
#P outlet 270 150 15 0;
#P window linecount 1;
#P newex 226 84 42 196617 == 4;
#P window linecount 2;
#P newex 226 114 42 196617 prepend set;
#P outlet 226 150 15 0;
#P window linecount 1;
#P newex 182 84 42 196617 == 3;
#P window linecount 2;
#P newex 182 114 42 196617 prepend set;
#P outlet 182 150 15 0;
#P window linecount 1;
#P newex 138 84 42 196617 == 2;
#P window linecount 2;
#P newex 138 114 42 196617 prepend set;
#P outlet 138 150 15 0;
#P window linecount 1;
#P newex 94 84 42 196617 == 1;
#P window linecount 2;
#P newex 94 114 42 196617 prepend set;
#P outlet 94 150 15 0;
#P window linecount 0;
#P newex 50 49 50 196617 zl slice 1;
#P window linecount 1;
#P newex 50 84 42 196617 == 0;
#P window linecount 2;
#P newex 50 114 42 196617 prepend set;
#P inlet 50 30 15 0;
#P outlet 50 150 15 0;
#P connect 1 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 2 0;
#P connect 2 0 0 0;
#P connect 4 0 7 0;
#P connect 7 0 6 0;
#P connect 6 0 5 0;
#P connect 4 0 10 0;
#P connect 10 0 9 0;
#P connect 9 0 8 0;
#P connect 4 0 13 0;
#P connect 13 0 12 0;
#P connect 12 0 11 0;
#P connect 4 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 14 0;
#P connect 4 0 19 0;
#P connect 19 0 18 0;
#P connect 18 0 17 0;
#P connect 3 0 20 0;
#P connect 7 0 21 0;
#P connect 10 0 22 0;
#P connect 13 0 23 0;
#P connect 16 0 24 0;
#P connect 19 0 25 0;
#P pop;
#P newobj 32 42 208 196617 p secret easyness;
#P newex 32 92 100 196617 funnel 6;
#P user led 122 67 17 17 0 150;
#P user led 104 67 17 17 0 150;
#P user led 86 67 17 17 0 150;
#P user led 68 67 17 17 0 150;
#P user led 50 67 17 17 0 150;
#P user led 32 67 17 17 0 150;
#P connect 7 11 13 0;
#P connect 7 10 12 0;
#P connect 7 9 11 0;
#P connect 7 8 10 0;
#P connect 7 7 9 0;
#P connect 7 6 8 0;
#P fasten 6 0 7 0 37 114 25 114 25 34 37 34;
#P connect 7 5 5 0;
#P connect 7 4 4 0;
#P connect 7 3 3 0;
#P connect 7 2 2 0;
#P connect 7 1 1 0;
#P connect 7 0 0 0;
#P connect 0 0 6 0;
#P connect 1 0 6 1;
#P connect 2 0 6 2;
#P connect 3 0 6 3;
#P connect 4 0 6 4;
#P connect 5 0 6 5;
#P window clipboard copycount 14;

–

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

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

Re: [funnel] bug?

David Stanford — Wed, 15 Mar 2006 21:26:33 +0000

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

Re: [funnel] bug?

Stefan Tiedje — Thu, 16 Mar 2006 19:29:49 +0000

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

Re: [funnel] bug?

David Stanford — Thu, 16 Mar 2006 21:31:36 +0000

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