Matrix operations not evaluated in order?

    Mar 11 2009 | 4:35 am
    I've attached a very simple program that's disobeying (as far as I can tell) the Max order of operations. In example1.maxpat, there's a matrix, and two "getcell" messages that query the matrix. Max supposedly evaluates depth-first and right-to-left, which would mean that the rightmost getcell fires first, followed by the matrix's response; then the other getcell message would fire, followed by the matrix's response.
    Instead, as is revealed by the print object I've included, the getcell messages both fire, and then the matrix objects fire.
    How can I fix this? It's really a problem for me, because I want to do different things with the results of the two "getcell" queries. In example2.maxpat, I've tried to use a gate to route the result of the first query to one place, and the result of the second to another. But as you can see, both messages from the matrix always get routed to the same outlet of the gate.
    Any ideas?

    • Mar 11 2009 | 6:23 am
      Works fine here, the messages come out gate outlet 2 then gate outlet 1.
      What revision of Max are you using?
    • Mar 11 2009 | 5:13 pm
      Really? So the two message boxes in example 2 both change value every time you hit a key?
      I'm using Max 10.5.6.
    • Mar 11 2009 | 6:02 pm
      Wo! is it running under winpple 25.hgsafgzg?
    • Mar 16 2009 | 11:05 am wrote on Wed, 11 March 2009 11:13Really? So the two message boxes in example 2 both change value every time you hit a key?
      yes, here they do... wrote
      I'm using Max 10.5.6.
      I wonder where you got that, I am on Max 5.0.6 which is the newest official one. Maybe you'd better downgrade as using time machines (the real ones not those from apple) is dangerous as far as I know...
    • Mar 16 2009 | 1:14 pm
      As you write in your patch, order matters. But you - don't - want to rely on the left to right order. Although it is reliable, it is dangerous for the following reason: in 6 months or so, you open your patch, you want to build on it, you move objects around, and things don't work anymore as expected. This becomes hard to debug. If order matters, you should use [trigger]. For instance in your example 2, after the modulo, use [t i 1 i 2]. Jean-François.
    • Mar 16 2009 | 5:43 pm
      > use [trigger]
      Thanks for the tip! What I had been doing was put a comment box, "ORDERED", at every intersection where order mattered. It helped a little, but you're right, debugging was still pretty ugly.