It happens to all Max programmers, you are happily patching away… and then suddenly Max will pop-up the top most patch window and display a yellow alert at the top of it.

The message should be dismissed by clicking the cross icon to the right of the message. But if you don’t change your message flow the error will likely pop-up again. What is wrong?


Remember that things happen in Max only when messages are being exchanged between the objects. If you see this error then somewhere in your patch an object that sends a message, receives a message back for every message it sends. And then sends a message again upon reception, ad infinitum. Max cannot deal with this situation. You should revise your message path (change the patch cords) to prevent this from happening.

You can find the object that signals the problem by clicking on the object name at the left of the yellow error message. Max will expose the window that contains the object and highlight it.

The patch on the right has the problematic message path. The button object sends a bang to the message box, the message box reacts by sending it’s contents (a message with the integer 1), the + object adds it’s internally stored value (the first time it is 0) to the received integer and sends a message with the result, that message is immediately send through the loopback patch cord to itself, that result causes another addition (again 0 is added) and the result is send, and … the error message is displayed.


This problem can be resolved by removing the patch cord that connects the outlet and the inlet of the + object. Of course at this point your patch does not accumulate values anymore. To get the require functionality you should use the right inlet of the + object.

Now the same message flow occurs as enumerated above. However, when the + object sends the result it is received by the right inlet. A new message in the right inlet does not cause the + object to send a new result. Instead it changes it’s internal variable for remembering the factor to add to incoming numbers. Repeatedly sending the value one thus creates the desired functionality in this case.

Infinite loops with send and receive

When your patches get more complex and especially when you use the send and receive objects throughout your patch, it may not always be apparent where the error occurs. Of course, by clicking on the object name to the left of the error message the culprit object is exposed. But it might be more difficult to isolate the feedback loop. In this example the subpatch links the send and receive objects that are linked by hup. In the last case a fix might be more difficult to find. In general it is wise to revise your system design and reroute patch cords so that the error no longer occurs…