How to force [zl] to ignore its control messages?

    Jan 29 2013 | 2:42 pm
    I just ran into this problem (and I'm surprised that I haven't faced this problem during the many years I've been using [zl]): if I try to process a list that starts with a word that is an actual control message for [zl], instead of getting it processed, I get an error message. Of course, this is normal behaviour, and under most circumstances, it won't cause much trouble (after all, the chances for an ordinary max list to start with something like 'zlmaxsize' is not that high). However, the 'mode' keyword can be quite tricky in this sense.
    To illustrate my problem, here's the following, tiny, almost-real-world-scenario example:
    Now, let's assume that there is a big patch with a lot of things (pattr-ed objects, parameters in [route] objects etc.) called 'mode' (which is my current scenario, unfortunately), and let's assume that someone (me, in this case) needs to implement a couple of mechanisms to intelligently hassle with lists controlling these objects. As far as I see, my only solution would be to rename everything called 'mode' in my patches to something else, so that it wouldn't confuse [zl].
    My question is: is there any other way to deal with this problem? For example, is there a way to force the [zl] family of objects to simply ignore the command messages sent to them?
    Or any other trick?
    Thanks in advance,

    • Jan 29 2013 | 3:01 pm
      It's nothing that you haven't thought about yourself but that's the only way to do that. We sadly just can't deprecated the mode message without breaking the compatibility.
    • Jan 29 2013 | 3:04 pm
    • Jan 29 2013 | 7:31 pm
      I try to do module-specific messages, like "aw.scalemode" and some such - that way it won't get munged up on the way through my system.
    • Feb 01 2013 | 5:28 am
      A bit of Max pedantry: technically, any set of symbols, numbers, etc. is NOT necessarily a list. The vast majority of the time, list processing objects will treat "foo 50 bar" as if it was a list, but technically a list must start with either a number or the symbol "list," the logic of that being that "rate 0.2" is a command rather than a list. So prepend the symbol "list" in front of your list, and you will never have this problem again.
      Dumb example attached.
    • Feb 03 2013 | 4:07 pm
      I wouldn't recommend messing around with keywords like int/float/list... But you're right, technically a list should always start with a number.