This is the first in a series on best practices for Max/MSP programming. Click here for an overview of the series.
What are Best Practices?
This attempt to think about best practices for Max grows out of frustration with my own Max programming practice, especially in situations where I am sharing my code with other Max programmers and need them to understand what is going on. I have found that Max’s graphical UI is great for quick programming, but it doesn’t take long for all of those patch cables to make an unintelligible mess of your patch. As your patches grow bigger and more complicated it becomes more difficult to keep track of what’s going on — and we all know that sinking feeling when we open an old patch and realize we have no idea how it works.
Best practices are programming guidelines which can help avoid these situations. Most programming communities have a set of best practices, whether they are explicit or implicitly stated. Their purpose is to make your program better in a variety of ways – and this set of blog posts is going to look at ways to help you:
- layout your patches so it is clear how they work
- make your patches be easier to use in performance
- be able to re-usable your work
- help your patches run fast and efficiently
- keep your patches working when moving to different computers or upgrading Max
While I will borrow ideas from text-based programming languages throughout this series, our set of best practices will differ both due to the way Max is designed as well as the fact that Max is primarily used to create music and art. I’ll focus on practices that help you use your own patches, but in some sections will talk about things that will help you share your patches with others.
This post presents an overview of what we are trying to achieve in choosing a set of best practices. Future posts will address each of these points in more depth.
Readability – taking the fear out of the unlock button
Making your patch readable means making it easy to understand what your code does. Probably the first thing you would think of is adding comments to your patch and naming number and message boxes so you know what they represent. Another key element is laying out objects in a sensible way, like keeping a signal flow from top to bottom. But there are lots of other ways to help make your code readable, and good habits can help make it easy to fix that bug in that patch you created last month.
Useability – thinking about the end-user
Presentation mode is a great thing, and an inherent acknowledgement that we want to see different things when we are using a patch versus when when we are creating it. But fundamental questions remain about what information and interactions we make available — a subject which is the entire focus of the field of human-computer interaction. And Max doesn’t always help things, especially when we start working with lots of parameters and different synthesis techniques. Here we will explore some principles of HCI as well as thinking about how to best use Max’s preset systems to make our patches approachable and understandable.
Reusing code – don’t waste your time re-creating the wheel
Max offers lots of ways to encapsulate and reuse patches, but creating useful abstractions can be tricky. We will borrow tips from other programming languages on how to make abstractions that are easy to re-use. We’ll also take a look at the way Cycling 74 and other Max programmers work in order to find a consistent way of creating helpful abstractions.
Efficiency – in an inefficient world
As wonderful as Max is, it isn’t the most efficient programming language, and both MSP and jitter can bring your computer to a halt pretty quickly. Luckily, Max has lots of ways of helping to tweak our patches to minimize what code is running. We’ll take a look at how this works in MSP as well as think about how to structure your program to get the most beef out of it.
Maintainability – beating the relentless upgrade cycle
Every time a new version of Max comes out the inevitable question arises – when are you going to switch? Max 7 sat unused in my app folder for months until I had time in-between projects to figure out its quirks. While Cycling 74 has done a good job of making Max backward compatible all the way to Max 5 there are still some key questions we want to think about in order to make sure the patch we are using today still works two versions of Max later. Along the way we will also talk about ways of making your patch portable so it will still work when you run it on a different computer.
What we won’t look at
What do you think?
Coming up with best practices is a difficult topic — and just as with everything else in the programming world, there are lots of possible approches. Communities have had heated conflicts over topics as seemingly trivial as proper indentation style. Since it is rare for Max programmers to work collaboratively in patches, your choice of programming habits can be a personal thing — and in this series I will be presenting my own perspective about what is useful and makes sense to me. But I’d love to hear your perspective as well! Chime in on the comments and let me know what your personal best practices are!