Forums > MaxMSP

Is it a bug with coll?

June 12, 2006 | 6:32 pm

When answering for the request of a subsym for numbers regarding coll I
came across this oddity, it might be a bug:
To make it work it needed a second deferlow, without it, it would put in
a wrong number, don’t know why…
Just wanted to point to it…

Stefan

#P window setfont "Sans Serif" 9.;
#P window linecount 5;
#P comment 321 203 80 196617 But if this > deferlow is missing I get a
wrong entry… (5 instead of 6);
#P window linecount 2;
#P newex 133 142 50 196617 prepend delete;
#P window linecount 1;
#P newex 133 178 50 196617 deferlow;
#P message 87 60 40 196617 4 6;
#P newex 87 91 40 196617 swap;
#P newex 87 178 40 196617 zl join;
#N coll ;
#T flags 1 0;
#T 1 1 1234 10;
#T 2 2 2354 20;
#T 3 3 3465 30;
#T 4 4 4567 40;
#P newobj 117 121 59 196617 coll;
#P newex 405 200 50 196617 deferlow;
#P window linecount 2;
#P newex 451 139 50 196617 prepend delete;
#P window linecount 1;
#P newex 451 175 50 196617 deferlow;
#P message 405 57 40 196617 4 6;
#P newex 405 88 40 196617 swap;
#P newex 405 175 40 196617 zl join;
#N coll ;
#T flags 1 0;
#T 1 1 1234 10;
#T 2 2 2354 20;
#T 3 3 3465 30;
#T 4 4 4567 40;
#P newobj 435 118 59 196617 coll;
#P window linecount 7;
#P comment 205 179 80 196617 < this deferlow is obviously needed for
assuring the result isn’t deleted before it will come out….;
#P fasten 9 0 8 0 92 209 200 209 200 114 122 114;
#P connect 10 1 8 0;
#P connect 11 0 10 0;
#P connect 8 0 9 1;
#P connect 10 0 9 0;
#P connect 8 1 13 0;
#P fasten 12 0 8 0 138 200 192 200 192 117 122 117;
#P connect 13 0 12 0;
#P fasten 7 0 1 0 410 222 520 222 520 108 440 108;
#P connect 2 0 7 0;
#P connect 6 0 5 0;
#P fasten 5 0 1 0 456 197 510 197 510 114 440 114;
#P connect 1 1 6 0;
#P connect 3 0 2 0;
#P connect 1 0 2 1;
#P connect 4 0 3 0;
#P connect 3 1 1 0;
#P window clipboard copycount 15;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


June 13, 2006 | 8:21 am

Hi Stefan,

I don’t think it’s a bug of coll, it seems to be a problem while
using deferlow. I don’t see any reason why deferlow is required,
trigger is enough.

Best,
ej

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 397 125 71 196617 $1 , delete $1;
#P message 348 63 40 196617 4 6;
#P newex 348 94 59 196617 swap;
#N coll ;
#T flags 1 0;
#T 1 1 1234 10;
#T 2 2 2354 20;
#T 3 3 3465 30;
#T 4 4 4567 40;
#P newobj 397 169 90 196617 coll;
#P newex 348 233 59 196617 zl join;
#P newex 92 144 75 196617 prepend delete;
#P newex 92 118 84 196617 t i i;
#P message 43 63 40 196617 4 6;
#P newex 43 94 59 196617 swap;
#N coll ;
#T flags 1 0;
#T 1 1 1234 10;
#T 2 2 2354 20;
#T 3 3 3465 30;
#T 4 4 4567 40;
#P newobj 166 185 90 196617 coll;
#P newex 43 233 38 196617 zl join;
#P connect 8 1 10 0;
#P connect 10 0 7 0;
#P fasten 6 0 7 0 353 264 494 264 494 159 402 159;
#P connect 7 0 6 1;
#P connect 8 0 6 0;
#P connect 9 0 8 0;
#P connect 3 0 2 0;
#P connect 2 0 0 0;
#P connect 1 0 0 1;
#P connect 2 1 4 0;
#P connect 4 1 1 0;
#P connect 4 0 5 0;
#P connect 5 0 1 0;
#P fasten 0 0 1 0 48 264 274 264 274 177 171 177;
#P window clipboard copycount 11;


June 14, 2006 | 5:05 am

Emmanuel Jourdan wrote:
> I don’t think it’s a bug of coll, it seems to be a problem while using
> deferlow. I don’t see any reason why deferlow is required, trigger is
> enough.

Yes, your patch is clearer and works, but still I don’t know why my
version without the second deferlow would create 5 instead of 6, that
was my concern, there was no value 5 incolved at all…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


June 14, 2006 | 5:11 pm

On 14 juin 06, at 07:05, Stefan Tiedje wrote:

> Yes, your patch is clearer and works, but still I don’t know why my
> version without the second deferlow would create 5 instead of 6,
> that was my concern, there was no value 5 incolved at all…

Right, didn’t see that. Does anyone have any idea where this 5 comes
from?

ej


Viewing 4 posts - 1 through 4 (of 4 total)