trouble with ordering and [if]


    Apr 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
    thanks
    -- robin

    • Apr 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
    • Apr 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
    • Apr 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
    • Apr 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
    • Apr 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 - www.lcasserley.co.uk Colourscape Music Festivals - www.colourscape.org.uk
    • Apr 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!!* *
      thanks again for all the help I've had on this. this list has saved my sanity many times
      -- robin
    • Apr 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 - www.lcasserley.co.uk Colourscape Music Festivals - www.colourscape.org.uk