vichug

If i type whole word "int" or "float" as arguments for [trigger], i get this message in Max console : "missing arguments for message "int" " (or "float") ; whatever message i send to [trigger]. Is this not a bug ? If it isn't, how to give an "argument" to an "argument" ?..should "int" not behave exactly as "i" ? or behave like a nomal string of characters ?

If i type whole word "int" or "float" as arguments for [trigger], i get this message in Max console  : "missing arguments for message "int" " (or "float") ; whatever message i send to [trigger]. Is this not a bug ? If it isn't, how to give an "argument" to an "argument" ?..should "int" not behave exactly as "i" ? or behave like a nomal string of characters ?


trigger-int-missing-argument-for-message-int

using "int" as type is not implemented as argument to trigger. but it should indeed be interpreted as a symbol/string IMO.

Fair enough. But right now, it's just buggy then ?... "float" and "list" seem to not give good results either

In a trigger object the correct arguments are 'b', 'i', 'f', 'l', and 's'. Other arguments will be interpreted literally as what they are. The word 'int' or 'float' is a special kind of message selector in Max that requires that it be followed by a numerical argument, e.g., 'int 74' or 'float 3.14'.

The point is that any integer message (e.g., 42) is essentially shorthand for the message 'int 42'. So, if you leave 'int' as a symbol on its own, you've got yourself an incomplete message.

Analogously for the symbols 'float', 'list', and (I'm pretty sure, although you didn't mention it) 'symbol'.

Given that these symbols all have special meanings in Max, getting them to work they way a naive user might expect may not be as easy as you might hope. I'd love to be proven wrong, but I'm not holding my breath.

Possible workaround: could you use symbols like, say, 'int ' (i.e., appending a blank or other invisible character, and wrapping the whole thing in double-quotation marks)?

Analogously for the symbols 'float', 'list', and (I'm pretty sure, although you didn't mention it) 'symbol'. 

Possible workaround: could you use symbols like, say, 'int ' (i.e., appending a blank or other invisible character, and wrapping the whole thing in double-quotation marks)?


@Christopher, @Peter : I see your point. Then the only problem I'd have with it is that it's only half consistent through objects. See how [route] behaves : it's the opposite, if an argument is "int" it will output an int through any matching outlet ; if an arg is "i" it will output only if it receives a "i".

Well i know it's not the same objects, not the same features, but still... not very consistent is it ?

I understand that you wish for objects to be more consistent so that you don't have to memorize as many things. But at the same time you're also right that "it's not the same objects". Each object has a different objective, a different behavior, and thus different standards.

In [route] the object is looking for specific "selectors" (the first item in a message). So you can look for a message that starts with "74", and route will strip that off and send the rest of the message, such as "74" (which will send out "bang", kind of an exception) or "74 75 76" (which will send out "75 76") or "74 skidoo" (which will send out "skidoo"). At the same time, a message "74" is actually a synonym for the message "int 74". And any message that is two or more items and begins with a number is actually a message of type "list". So you can look for the message "int" more generally, which will send out the argument of the message (in this case "74") for any integer. And you can look for the message "list", which will strip off the (possibly invisible) word "list" and send the rest of the message.

In [trigger] (also abbreviated [t]), the arguments are just indicators of the type you want to convert the message to, not the literal word that you want it to send out, unless you type in a literal message rather than one of the indicators.

In [pack] or [pak] you initialize the output value and imply its type at the same time.

In [route] the object is looking for specific "selectors" (the first item in a message). So you can look for a message that starts with "74", and route will strip that off and send the rest of the message, such as "74" (which will send out "bang", kind of an exception) or "74 75 76" (which will send out "75 76") or "74 skidoo" (which will send out "skidoo"). At the same time, a message "74" is actually a synonym for the message "int 74". And any message that is two or more items and begins with a number is actually a message of type "list". So you can look for the message "int" more generally, which will send out the argument of the message (in this case "74") for any  integer. And you can look for the message "list", which will strip off the (possibly invisible) word "list" and send the rest of the message.

In [pack] or [pak] you initialize the output value and imply its type at the same time.


vichug: why would anyone like to set an argument of "int" or "list" to a trigger object? you can not send this symbol out of the object anyway.

"Each object has a different objective, a different behavior, and thus different standards." It's not true most of the time. And it's better when you can guess how an object will behave, based on previous knowledge ; that's what makes Max a sensible language rather than a hopeless chaotic cluster (even if that's debattable...)

Anyway ok, i understood the problem and my initial error of appreciation.

"Each object has a different objective, a different behavior, and thus different standards." It's not true most of the time. And it's better when you can guess how an object will behave, based on previous knowledge ; that's what makes Max a sensible language rather than a hopeless chaotic cluster (even if that's debattable...)
Anyway ok, i understood the problem and my initial error of appreciation.


[trigger int] : "missing argument for message "int" "