afaik, [route list] never let a generic message (a b c d) through its left outlet. It surely hasn't since Max 4.6.
[trigger] is a different story - [t l] will let _anything through (be it an int, a float, a list or a generic message) - hence a lot of confusion...
... my humble opinion is that all this message type-checking stuff is one of the most obsolete and convoluted parts of Max. It made things faster on the slow machines of the days of old, but if Max was created now I'm pretty sure it wouldn't exist. But of course throwing it away would mean breaking the compatibility with 20+ years of patches made by people around the world, and this would definitely be a very bad idea...
To my understanding the trigger object is much more like type conversion; [t l] will convert the input to the type list—whatever that means. But I feel the same. Only the ministry of silly walks can explain this:
>this would definitely be a very bad idea...
Maybe at some point the price of retaining backward compatibility becomes too high. Maybe that point is near...
ok guys, i might have been wrong, as it seems i only had luck the last 10 years by not running into a [route list] issue.
but like andrea says, trigger handles it that way. zl does, too.
so [route] and [select] seem to be the exceptions, and most other objects treat quasi-lists "wrong"? interesting idea. :)
what i find even more strange is that there is no [list symbol] (at least in max v4), which means that you need the rightmost outlet to find symbols. so on the one hand [route] is anal about what is technically a list and what not - but on the other hand it can not even filter all types of messages.
Well, here is what happens under the hood: Max messages are always composed by a symbol, followed or not by other things - integers, floats or other symbols. This first symbol is called "message selector". In some cases the message selector is explicit: if you send the message A B C, then
A is the message selector, B C are the arguments.
In other cases, the message selector is hidden, and automatically chosen for you by Max. In particular, an integer's message selector is always int; a float's is always float. This means that whenever you send around a number (say, 74) what actually travels through your patch cords is int 74. Only, you don't usually see the "int" part.
Now, if your message is made up of several elements there are two cases:
- the first item is a symbol (as in the A B C example above). In this case, the message selector is A, and all that follows are the arguments.
- the first item is a number (as in 1 2 3, but also in 1 B C). In this case we need a message selector, and so Max puts one for us: this message selector is "list".
Most objects (e.g. zl) hide these gimmicks from the user. So, [zl len] of A B C and [zl len] of 1 2 3 will both be 3, regardless of 1 2 3 actually being list 1 2 3.
The route object is a different story: it really lets you work with message selectors. So [route foo] means "output everything that has foo as its message selector", while [route list] means "output everything that has list as its message selector". Then, new appropriate message selectors are added to the output if needed.
[A B C]->[route A] will recognize the message selector A. So the stuff to output is B C: message selector B followed by the argument C.
[A 2 3]->[route A] will recognize the message selector A. So the stuff to output is 2 3: message selector list followed by the arguments 2 3.
[1 2 3]->[route list] will recognize the "hidden" message selector list. The stuff to output is 1 2 3, which again requires the message selector list.
There are also some things that you technically can do to make Max unhappy - sometimes triggering error messages, sometimes not, but potentially disrupting the good operation of the objects that wil receive them: