Usability improvement that may or may not be feasible

    Oct 21 2011 | 5:31 pm
    I wonder how hard it would be for the patcher to tell you when you've done something that depends on geometry for ordering in a significant way--in other words, when you have created a patch that would produce different (externally visible) results if you moved objects around, thereby changing implicit ordering.

    • Oct 21 2011 | 7:06 pm
      not sure if this is what you mean, but i think one piece of key info missing in max is the order that messages are sent out from an outlet to multiple destinations. having to keep track of right-left order in a big patch with lots of logic... that's the only thing that feels silly or even comical about patching to me.
      i was thinking you could mouse over a patch cords, and any other cords sharing that same source will flash in order, kinda like coords flash in debug mode, repeatedly as long as the mouse is hovering, so you get a quick feel of order. maybe if you move an object, any cords whose order changes could flash once.
      now that i think about, a feature as simple as an alternate color for all cords connected to the selected object would be a huge new feature. just making it easier to quickly see what's connected without having to chase patch cords down with your eyes.
      i'm a hawk about paying attention to it now, but i can't tell you how many times in my learning days i had to chase down bugs caused by inadvertently moving an object left or right in relation to the objects feeding it. very hard for me to catch this stuff in the debugger unless i step through slowly and attentively. max and slow development are arch-enemies.
      minor issue though, compared to how awesome max is in general.
    • Oct 21 2011 | 11:16 pm
      I highly recommend familiarizing yourself with the [trigger] object, which can help to resolve these concerns.
    • Oct 22 2011 | 4:39 am
      I understand the point of the trigger object. What I'm suggesting, though, is that it would be nice if the patcher could warn you "This patch relies on geometrical relationships between objects for its behavior, so you really should be using a trigger here" where appropriate.
      It's analogous to having a C compiler warn you about an expression used as a condition with an assignment as its top-level operator. That is:
      if (x = y) { /* whatever */ }
      is well defined in C, and means the same as
      if ((x = y) != 0) { /* whatever */ }
      but it's a pretty good chance that whoever wrote that code really intended to write
      if (x == y) { /* whatever */ }
      If you're trying to make your compiler more usable by people without a lot of experience, it's pretty easy to make the compiler warn about this kind of usage on request.
      By analogy, I'm suggesting that it might be useful if the patcher could detect ordering dependencies that are resolved by objects' relative position--again, on request.
    • Oct 22 2011 | 9:10 pm
      Good luck, how should Max find out if its significant or not? I would be scared by a program that knows what I want to patch, as I am not needed as creator anymore, it would read my brain, and patch all automatically by itself...
      There is no problem to use a trigger always, as the only other solution would be to warn you always as soon you patch a second cord to an already connected outlet. This would be extremely annoying, as it isn't that often that it matters...
    • Oct 23 2011 | 12:59 am
      I said at the beginning of this discussion that I did not know whether it was feasible, but it seems to me that if two or more outputs from a single object have paths that lead to two or more inputs to a single object, that creates an ordering dependency; in such a case it should not be too hard for the patcher to inspect the patch and determine whether the dependency is resolved by trigger objects.
      I don't know Max well enough to be able to say for sure whether it's feasible, which is why I was suggesting the idea.
      I certainly don't want the patcher to know what I want to patch. However, such knowledge is quite different from the knowledge that the patch's behavior would change if I were to move some objects around on the canvas.