It is one thing to adapt max patches for maxforlive but it is another thing entirely to construct them so they can handle multiple instances without stepping all over each other by accessing the same data. Then there is the issue of telling monomeserial which instance has control of the monome hardware.

I wanted to make it elegant to use. For example, if you click on a track in live that has a monome application running, that monome application is in focus on the hardware. It is this level of integration that makes maxforlive so appealing. So, now you can run as many obos, polygomes, stepfilters, or automatorgators as you like, and the monome switches between them effortlessly.