[route list] fail?
Shouldnt this come out of the left outlet?
Many thanks in advance
Joe
Technically, this is a message with arguments. I'm not sure if this worked the way you expect in the past, but it doesn't seem to in Max 6.
*facepalm* why, c74, why?
Say something in the helpfile, at least
This is covered in this thread:
It probably would help out if basic tutorial 3, which states:
"A combination of numbers and text is called a list; the list is a mechanism for keeping data together into a single message that can be send via patchcords to other objects."
was a little clearer that it must start with a number (or the symbol 'list')to be a real list....
M
Not a bad idea, Matt. I guess someone thought that it was too obvious. I'll make Basic Tutorial 3 more obvious. :-)
Well, she do say "basic" =P
mzed: isn´t 1 2 3 4 5 also just a number with 4 arguments? thats what [printit] says, at least.
if his example does not work in max 6 i would call this inconsistency, if not more.
Roman; they ay in another thread that a list must start with a number. Free beer to anybody who finds that in any documentation.
well i know that we dont '_call it a "list" if it begins with a symbol, but why did it work in previous version of max to treat those as lists? :)
Well, I didn't. My point is, surely it is documented somewhere?
My printint calls 1 2 3 4 a list:
printit Version 0.4, by Matt Wright.
Copyright (c) 2000-06 Regents of the University of California. All rights reserved.
printit: received LIST with 4 argument(s):
LONG 1
LONG 2
LONG 3
LONG 4
I didn't make these rules, but that's how it is.
@roman what is different from previous version? I got the same result in Max 4/5/6 here:
Hi.
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...
my 2 cents
aa
@andrea
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...
I wouldn't mind.
In fact, thinking that [t l] converts everything to a list is not accurate... it really outputs everything as it was received.
Look at this:
hope this sheds some light...
aa
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.
-110
@andrea : damn... so a list really has to begin with a number to be a list ?... how broken :/
here's what printit says of the 3 message boxes in your patch :
printit Version 0.4, by Matt Wright.
Copyright (c) 2000-06 Regents of the University of California. All rights reserved.
printit: received an int: 1
printit: received LIST with 4 argument(s):
LONG 1
LONG 2
SYMBOL "c" (0x6a7d60, s_thing 0x0)
SYMBOL "d" (0x6a7d68, s_thing 0x0)
printit: received MESSAGE "a" (0x6a7d50, s_thing 0x0) with 3 argument(s):
SYMBOL "b" (0x6a7d58, s_thing 0x0)
SYMBOL "c" (0x6a7d60, s_thing 0x0)
SYMBOL "d" (0x6a7d68, s_thing 0x0)
so i tried this :
:D
obviously, the output is not of type "message"
Certainly it is possible to select by negation:
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:
... does it all make sense?!?
@andrea : thanks, indeed it does and it's clear now. In short, a message must always begin with a symbol in Max, and that symbol has always to be a message type identifier.
If only there was some files that were distributed with max, that were meant to contain all this fascinating information =P.
There's no reason in the universe that you couldn't add something about this to the Wiki. Knock yourself out.
the maxmspish conjunctive: someone should write about it in the wiki.