Max Basic Tutorials Bug?
Hello, I've been eager to get into Max/MSP for quite a while and finally have some time to start digging in. I've decided to start by following the Max Basic Tutorial available from the Cycling '74 website.
In Tutorial 3: Numbers and Lists, I've come across something that confused me and I wonder if it's a bug caused by a collision between current Max version and older tutorial materials, or something else I'm not understanding.
The first example patch in the tutorial demos a number box. There are: a button, 7 messages (some positive and negative integers, a decimal number, a text string), an integer number box, and a print object with argument 'int' comprising the patch. The button and each of the messages send to the number box, and the number box sends to the print object.
The issue arises when sending anything other than the text string through the number box to the print object. The text string handles properly, printing 'number: doesn't understand <string>' in the console. Sending any of the integers or other numerical data through to the print object prints the expected output ('int: <number>') but also raises an error in the actual console ('sprintf: missing arguments for message "int" '), and displays no output in the patcher/chooser in-patch simulated console. If I modify the 'int' argument to something else, like 'whole_number,' everything works as I would expect from reading through the tutorial, no errors.
I have looked into this a bit and determined that the error issue might be related to 'int' existing as a reserved keyword in the underlying environment. I assume the issue with the simulated console output has to do with the configuration of the chooser. In any case, I found this to be a confusing occurrence within the tutorial. I would be interested in learning more about what exactly is causing the issue, and it may be worth resolving in future versions of the basic tutorial to avoid confusion.
not sure if i fully understand and i dont have the tutorial files here, but
'number: doesn't understand <string>'
is not printed by the [print] object, objects throw those errors themselves if the console is open.
and "int" is indeed one of the reserved/partially reserved strings, beside "float", "list", "symbol", "bang", "set" and eventually "send" and "text".
but none of them is illegal! it is just not very clever to attempt to use them for custom commands, as they produce a predetermined effect in many/most/all objects.
from a user perspective/perception the list "int 5." sends "5"out of the messagebox object, the string never reaches the numberbox.
(technically it is more or less the other way round, any "5." is in fact "float 5.000000 or something along that line. i have never seen anyone writing "int" or "float" in a messagebox, such things are hardly ever needed except with "symbol" preceding numbers, which in this case changes the obvious data type of the number to symbol.)
p.s.:
if you want to actually send the message "int 5." somewhere you need to type it with the quotes (like we usually denote messages here in the forums) - or type "list int 5.", but this time without the quotes, because otherwise "list int 5." with quotes will be a symbol.
whatever, lists may also start with a number, 1 2 3 4 5 does not need "list" at the beginning. (you will see that 1 2 3 4 5 sent to print has a space at the beginning, thaht means it is a list)
oh, and dont bother typing "list" into messageboxes, there i a [list] object which is more elegant to hold lists. it is the same object as [pack] but with a different name.
i hope the confusion is perfect now. :P
you might want to install [printit] to get a more verbose feedback in the console, it ths perfect teacher about and debugger with data types.
Nice catch!
If you double-click on sprintf in the console, it will show you the object causing the error.
Here is a patch isolating the parts of the tutorial OP is talking about.
Here is what happens: the number box sends messages (of type int but could be anything else) to [print int]. The argument in [print] is an identifier, which makes the messages to appear in the console starting with the argument (here `int`). So far, so good.
The problem arise inside of [p console] (you can double-click it to open-it in the tutorial. I've de-encapsulated it in the patch I posted for clarity). We have that [console] object in there which throws out in the patch what comes in the console. Print identifier or object name come from leftmost outlet, rest of the message from middle outlet. Which means we have that "int" message coming from the leftmost outlet, alone. But the thing is, as you guessed and as Roman said:
"int" is indeed one of the reserved/partially reserved strings, beside "float", "list", "symbol", "bang", "set" and eventually "send" and "text".
but none of them is illegal! it is just not very clever to attempt to use them for custom commands, as they produce a predetermined effect in many/most/all objects.
Most objects won't expect an "int" message coming alone, and so they'll throw an error in return. That's what [sprintf] does. I would say in this case it's an oversight from Cycling74. Definitely worth reporting by filling a support ticket here!
Thank you for the explanations! Not confusing at all, this clears up some things I was wondering about and plenty of helpful additional tips too.