Forums > MaxMSP

trouble with ordering and [if]

April 10, 2006 | 6:39 pm

aaaaargh!

this patch sometimes works, and has been frustrating me to the point i can’t
think straight any more.

I’m guessing i’ve screwed up somewhere in the logic of it, but can’t figure
out where

max v2;
#N vpatcher 10 59 565 628;
#P window setfont "Sans Serif" 9.;
#P window linecount 4;
#P comment 341 477 186 196617 if number in left inlet ($i1) is not equal to
number in right inlet then send $i1 out the left outlet. if it is equal then
send it out the right outlet;
#P button 280 510 15 0;
#P button 123 510 15 0;
#P number 302 510 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 145 510 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 145 476 167 196617 if $i1 != $i2 then $i1 else out2 $i2;
#P number 145 381 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 243 185 27 196617 + 1;
#P newex 145 347 27 196617 + 1;
#P newex 156 302 35 196617 select;
#P newex 173 221 38 196617 t 0 i;
#N counter;
#X flags 0 0;
#P newobj 145 254 66 196617 counter;
#P number 173 185 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 173 126 15 0;
#P newex 173 156 52 196617 random 6;
#P number 124 126 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 76 34 15 0;
#P newex 76 156 58 196617 metro 500;
#P window linecount 2;
#P comment 280 428 45 196617 displays dice roll;
#P window linecount 3;
#P comment 182 381 63 196617 counts from 1 to random number;
#P window linecount 11;
#P comment 291 139 100 196617 rolls a dice , then counts from 1 up to that
roll (simulates how a player moves a piece a step at a time on a game
board). seperates the actual number of the roll from the numbers counting up
to it;
#P number 243 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P connect 5 0 4 0;
#P connect 16 0 19 0;
#P connect 6 0 4 1;
#P connect 4 0 10 0;
#P connect 10 0 13 0;
#P connect 13 0 15 0;
#P connect 15 0 16 0;
#P connect 16 0 17 0;
#P connect 10 0 12 0;
#P connect 5 0 8 0;
#P fasten 12 0 8 0 161 327 231 327 231 116 178 116;
#P connect 8 0 7 0;
#P connect 7 0 9 0;
#P connect 9 0 11 0;
#P connect 11 0 10 2;
#P fasten 9 0 12 1 178 210 220 210 220 287 186 287;
#P connect 11 1 10 4;
#P connect 7 0 14 0;
#P connect 14 0 0 0;
#P connect 16 1 20 0;
#P connect 0 0 16 1;
#P connect 16 1 18 0;
#P pop;

thanks


robin


April 11, 2006 | 1:33 am

the problem is, that the 2nd inlet of [if] gets updated with a new
random number before the current count reaches the 1st inlet …
so you may move the [select] below the counter slightly to the left of
the [+1] below counter … or you may use a trigger … or insert a
[pipe] somewhere between output of [random] and 2nd inlet of [if].

oliver


April 11, 2006 | 9:11 am

hi. thankyou so much! i just worked that out myself but still wasn’t quite
believing it. well, that solved that.
much appreciated


robin


April 11, 2006 | 1:38 pm

Quote: oliver griem wrote on Mon, 10 April 2006 19:33
—————————————————-
> the problem is, that the 2nd inlet of [if] gets updated with a new
> random number before the current count reaches the 1st inlet …
> so you may move the [select] below the counter slightly to the left of
> the [+1] below counter … or you may use a trigger … or insert a
> [pipe] somewhere between output of [random] and 2nd inlet of [if].
>
> oliver

… [bondo].

-110


April 11, 2006 | 2:47 pm

yeah, i was experimenting with bondo when i discovered all i needed to do
was move [select] to the left of the counter. it was all to do with my
ignorance of the right to left ordering. i’m too impatient!! really, thanks
a lot for your help though guys


robin


April 11, 2006 | 3:23 pm

I think this is a good point to add that, IMHO, relying on position of
objects for critical timing issues is a bad habit to get into – it is
so easy for something to get moved inadvertantly, and your patch is
broken. I was fortunate to have been brought up on Max/fts on the ISPW,
where the position of objects did not affect the timing, so I knew the
only way to ensure correct timing was to use ‘trigger’. IMV good
programming practice says _always_ use trigger when timing is crucial –
that way your patch is safe! It is also much easier to understand.

Best

L

Lawrence Casserley – lawrence@lcasserley.co.uk
Lawrence Electronic Operations – http://www.lcasserley.co.uk
Colourscape Music Festivals – http://www.colourscape.org.uk


April 11, 2006 | 3:44 pm

On 11/04/06, lawrence casserley wrote:
>
> I think this is a good point to add that, IMHO, relying on position of
> objects for critical timing issues is a bad habit to get into – it is
> so easy for something to get moved inadvertantly, and your patch is
> broken. I was fortunate to have been brought up on Max/fts on the ISPW,
> where the position of objects did not affect the timing, so I knew the
> only way to ensure correct timing was to use ‘trigger’.

thanks for the advice, definately something I’ll try to tke on board.

IMV good
>
programming practice says _always_ use trigger when timing is crucial -
> that way your patch is safe! It is also much easier to understand.

IMV? i tried to google it but i got the Institute for Molecular Virology,
and I doubt they recommend programming
techniques!!*< http://virology.wisc.edu/IMV/>
*

thanks again for all the help I’ve had on this. this list has saved my
sanity many times


robin


April 11, 2006 | 4:24 pm

On 11 Apr, 2006, at 16:44, robin foster wrote:

> IMV? i tried to google it but i got the Institute for Molecular
> Virology, and I doubt they recommend programming techniques!!
>
Well you never know – a lot of versatile peole out there!

I have always known it as "In My View"; companion to "In My Humble
Opinion"

L

Lawrence Casserley – lawrence@lcasserley.co.uk
Lawrence Electronic Operations – http://www.lcasserley.co.uk
Colourscape Music Festivals – http://www.colourscape.org.uk


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