I find Max/MSP to be a unique and interesting software suite, with great potential for rich interactive and multimedia projects. It simultaneously displays great potential, but that which is is seemingly limited by its lack of widespread use and community. I’m not entirely confident that this really is the case, and sure, the Cycling74 Forums are about as active as I could reasonably expect, but I often seem to run into issues or ideas that aren’t widely experienced.
One of these issues is finding pre-made patches and components. It is common to find a forum post describing a synthesizer or audio effect, but these posts are often over 10 years old and pertain to older versions of the software. Not to mention the chances of finding a link that actually lead to a file download, rather than a 404 or Mediafire account termination, can be slim. I find it incredibly useful to load someone’s patch to see what creative ideas they have implemented — something that is particularly helpful for this type of software.
By publishing this, I hope to alleviate some of these issues for those who wish to work with controller input in Max. This post details both the technical aspects of the input handling, as well as how to use this patch in a greater project.read more
The primary use for Max that appeals to me is interactive, real-time control. Its audio and visual tools are plentiful, but the real magic is in combination with logic and data processing. You can create an interactive experience — where you are playing with a dynamic musical instrument, or a visual/spatial playground where your movements become manipulated geometry — but where Max shines is its capacity to combine these types of experiences.
I have found that game controllers are very effective devices for interfacing with these programs. They’re already ergonomically designed for familiar input without needing to glance at the controls. Wireless connectivity allows for greater immersion and flexibility, such as within VR applications. The drivers are also readily available for almost any host system and input device.
For example, with the Wireless Xbox One controller, the binary input methods include:
- four generic buttons (A, B, X, Y)
- two shoulder buttons (L1, R1)
- directional pad (N, S, E, W directions)
- select and start buttons
And the dynamic input methods include:
- two analog triggers (L2, R2)
- two analog sticks
In total, this controller gives you fourteen binary switches, two X/Y coordinate pairs (somewhat), and two linear pressure-sensitive values. This is plenty of input for controlling some complex patches, especially so if creative interface design is taken into consideration.
It is also very convenient that Microsoft decided to use Bluetooth as the connectivity protocol for the Xbox One S controllers, rather than a more proprietary solution as was true with the Xbox 360. I have been able to use wireless Xbox 360 controllers with Max in the past, but not requiring an adapter is a definite advantage.
The patcher is based on a post by vincentrieuf in the Cycling 74 forums. I wasn’t able to use it immediately, as my button presses wouldn’t register correctly, but it is simple enough to modify it into something useful for my purposes.
My revised patch is designed in such a way that it can be adapted to another arbitrary controller, via changing the ‘route’ codes to the values appropriate to a given controller. When the ‘hi’ object is given a valid device as input, a bubble will appear within the patch, and the same output will be logged in the Max console.
Something that I found to be productive when creating this patch is the ability to create ‘proxy’ patch cords in Max. That is, instead of linking two objects as you normally would by connecting patch cords, you create ‘send‘ and ‘receive‘ objects. This means that while the total object count of the patch might be higher than necessary, the amount of headache is substantially reduced once your projects become more complex.
The patcher additionally contains descriptions next to the appropriate object groups for the given input method.
A benefit of this patcher is its ability to quickly call a given input, by creating an ‘r’ object with the corresponding input code.
These codes are given below. The code column is how the input is identified; to use it, create an ‘r’ object with the code as the first and only argument.
Input Code Type dpad N dp_n bang dpad E dp_e bang dpad S dp_s bang dpad W dp_w bang dpad NE dp_ne bang dpad SE dp_se bang dpad SW dp_sw bang dpad NW dp_nw bang left analog X ls_x float, 0-65535 left analog Y ls_y float, 0-65535 right analog X rs_x float, 0-65535 right analog Y rs_y float, 0-65535 left bumper l_bm bang right bumper r_bm bang bumper reset bm_r bang, reset left trigger l_t float, 0-1023 right trigger r_t float, 0-1023 button A b_a bang button B b_b bang button X b_x bang button Y b_y bang button reset b_r bang, reset button select select bang button start start bang button ss reset ss_r bang, reset
This organizational structure allows the input-handling components of a given project to be mostly hidden. Max allows the creation of subpatchers, or encapsulations. This is helpful, as it allows the controller input logic to be hidden.
I hope this is a useful tool for some creative Max projects, and it certainly will be for mine going forward.