Another post on MaxMSP basics – this time on object arguments and right-to-left order of operation.
Object Arguments
Most MaxMSP objects can be initialized with certain values through the use of arguments. For example, you can tell a metro how fast to go by typing an initial time value (usually in milliseconds) as an argument. Math operators work the same way. Arguments can save you the trouble of having to send messages to every object each time you open the patcher.
Object inlets often (but not always) correspond to an object’s arguments, working right-to-left. Using makenote as an example:
The arguments for makenote are velocity (127) and duration (1000 ms). Starting on the right, the inlets are for duration and then velocity (center inlet). Sending messages to makenote to change velocity or duration will not change the display of the initial arguments that were typed when the object was created. But velocity and duration messages sent to makenote will be stored by the object and used whenever a note number is sent to the left inlet.
Right-to-Left Order of Operation
We’ve already discussed in class that computers are stupid – they only do what they are explicitly told to do. They don’t infer meaning or predict the next logical step. You have to tell them exactly what you want them to do. Related to that explicitness is the need for a predictable order of operation. You have to know in what order steps will be executed so that you can receive valid results for specified problems. In text-based programming languages order of operation is usually from top to bottom of a program (or sub-routine), with each line being one command. In a graphic programming language there isn’t a single flow of execution.
MaxMSP uses right-to-left order of operation. Right-most outlets send messages first, moving towards the left in order. In the following example, clicking the top button will cause the other buttons to bang in the order specified.
This right-to-left order matches up with object arguments quite well. Arguments to the right are stored for later use, while a message to the left-most inlet will trigger an object to perform its function.
To add to our operation order, consider that usually when an object performs its function it sends a message out it one or more outlets. Take a look at the next example:
The top button will output to its right-most patch cord first, just as before. But now, with its outlet connected to another button, it will output a bang to button 2 next, and the button 2 will bang to button 3. Since there is not a connection out of button three, the top button will send its message out the next patch cord to the left, to button 4. Button 4 then sends its message to button 5. Etc.
It is very important to note that the order of operation for the above buttons would change if I moved them around on screen – even if I didn’t change any of the patch cord connections. For example, if I took button 6 and moved it to the right of button 1, button 6 would be triggered before button 1. Many errors, especially starting out, can be traced to out-of-order operations. At some point we will talk about the step trace function which can help you debug patchers by watching the patcher execute step-by-step with a pause.
Leave a Reply