$Adam

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 

): if I try to process a list that starts with a word that is an actual control message for 

, 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 

My question is: is there any other way to deal with this problem? For example, is there a way to force the 

 family of objects to simply ignore the command messages sent to them?

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.

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?

how-to-force-zl-to-ignore-its-control-messages

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 

 message without breaking the compatibility.

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.


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.

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.

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.

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.

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