Max 5: What It Is (and Isn't)

Some of you may have heard that major changes are imminent in the Max world, and there is a lot of speculation about what those changes might be. On the eve of our first public exposition of the new version of Max at the AES convention in New York, I thought it would be appropriate to offer some details on the product.

Max 5 will be released in the first quarter of 2008, and will include (and require) new versions of MSP and Jitter. While MSP and Jitter will have some enhancements, the real story is the environment itself.

Many software companies seem willing to claim that every problem you could possibly have will magically be solved by upgrading to their latest version. But often as not, upgrades mean changes in the way you're used to working and new compatibility problems. I wish I could say that you'll be able to start using our amazing new version and everything will sparkle (including your clothes). But I'd rather be honest and say that the reality of software development is that in order to get shiny and sparkling, you have to be willing to make big changes. Max 5 represents one of those times. In almost twenty years of working on this software, there's never been anything close to the transformation we're undertaking.

What We Changed

For current users, I would describe Max 5 as analogous to Apple's transition from Mac OS 9 and Mac OS X. At some point, Apple decided that the technological foundation of their operating system was unsustainable, and required a completely new approach. We came to the same conclusion about many aspects of Max, and especially about the graphical interface -- often the most complicated and difficult system within any large application software project.

Max was based on the way the Macintosh worked in 1987. Since then, a lot of things have changed about graphical interfaces, file systems, and pretty much everything else. As a result, the assumptions of 1987 were simply too deeply embedded to keep Max going for another 20 years with the same internal codebase. This became increasingly apparent in recent years, as we seemed be doing nothing but patching Max to keep it working with the latest hardware and software.

If you write computer programs, you have two jobs: you can make the programs do new things by adding features, or you can fix your programs to be compatible with something. Adding features is fun. Maintaining compatibility is entirely necessary, but for me it's not very fun. And I don't think many other people find it fun either.

I've wanted to make Max better, but recently most of my work has been the drudgery of making it operate on OS X, or on Windows, or on Intel processors. While I've been doing this, I've also been accumulating ideas for what I would do once I got over all this kind of work.

Well, that day did come when we finally finished the Intel port of the OS X version, although it took about a year longer than I thought it would. Once I was able to clear that off my desk, I began organizing my thoughts about what Max requires to survive another 20 years.

There are two aspects to this. First there is the boring part - if Max is going to survive another 20 years it needs to be rewritten to work easily on multiple operating systems, on diverse hardware, and in various places of the world. Second (and less boring) is that Max has to change to fit the way people use computers in 2007, rather than the way they used them in 1987.

One of my dreams is to avoid wasting an entire year's effort the next time a hardware or software transition is forced on us. We were going to build Max on top of a platform-independent framework that will isolate us from the day-to-day nonsense Apple and Microsoft keep throwing at us. And, ultimately, we want to port Max to Linux. (No, we haven't done this yet, but we can now conceive of doing it.)

Getting rid of our "legacy of dependence" stretching back to the Mac OS circa 1987 takes some time, which is why you haven't seen a new version of Max in a while. But you will soon, so let's talk about the second part of the project -- rethinking how people work with Max.

What We Didn't Change

Max 5 doesn't add hundreds of new objects. There are a dozen or so, but Max has enough objects already. It does not go crazy with social networking features, or run your cell phone, or introduce an exotic new computer science paradigm of object-oriented goodness. I'm not saying those aren't worthy things to do, but that's not what Max 5 is about. In other words, you still use the same basic collection of objects in the same way.

So, Exactly What Did We Change?

Max 5 is based on being easier to use, easier to learn, and easier to deal with. In order to work toward those goals, we've put a lot of effort into creating a more modern graphical user interface for interactive real-time graphical programmers. I should point out that a programming environment is not the first thing that people have in mind when they think about graphical user interfaces.

I can't provide an exhaustive list, but let me highlight a few of the ways we addressed each of the three areas discussed above.

Easier to Use

1. Multiple undo is available.

2. Objects interact with time in ways that are more meaningful than milliseconds.

3. The patcher is variable resolution and can be zoomed in and out.

4. A simplified and more consistent interface, identical on Mac and Windows.

5. A new object palette (with nice big resizable icons!) works as a visual catalog.

Easier to Learn

1. The documentation is completely integrated into the user interface.

2. A searchable database of objects, media, examples, and documentation integrates all of the provided material.

3. Introductory tutorials have been completely rewritten, and include integrated patches.

4. New interactive debugging tools make figuring out what your patch is doing (almost) fun.

5. Third-party object developers can now use all of our documentation tools for their products.

Easier to Deal With

1. The interface can easily be localized and customized.

2. A new file format is more readable, extensible and reliable.

3. Support for Unicode text and filenames.

4. A new interface layer -- "Presentation Mode" – provides a new way to build user interfaces without cluttering your patch.

5. The installation and authorization experience is vastly improved.

Behind these ease-of-use goals you will find a lot of new software technology that we've been working on for over two years. I won't bore you with the details, but pretty much every piece of Max (except the part that runs your patch) has been modernized. We've dropped the MDI interface on Windows in favor of a more elegant SDI model. The graphics are composited (which means things can be translucent), and the programs are remarkably identical between platforms. And because we needed it for our documentation, we'll let you drop a web browser into your patcher whenever you need one.

Why Make Max Easier?

A few years ago we conducted a survey of Max users, and the results completely changed the way I thought about the software. What became clear was that Max users do not think of themselves as working with sound, or images, or controllers. Instead, they see themselves as working with ideas. Max, therefore, is more of a concept editor than a media editor.

Because Max users are concerned with cognitive problems, I realized that in order to be effective software, Max could not itself be a cognitive problem. There are many challenges in trying to think while using a computer, but to me, there was a simple and fundamental aspect of using Max we could immediately improve: remembering how things work.

Perhaps you have memorized how everything in Max works. I have not – I am constantly consulting the help files and documentation, and I feel that every moment I spend looking for the PDF or deciphering a help patch takes my concentration away from the problem at hand. We tried to look at every "moment" in the life of the Max programmer, and want to make the information that applied to that situation immediately available.

Let me give you just one example of what I'm talking about. In Max 4.x there was something we call the "quick reference" menu. You might not even know about it because it involves clicking on an object with two keys held down (and naturally, I can't remember which ones they are right now!). We've improved this feature in a number of ways. First, to see the menu, all you have to do is click on the inlet of the object. A menu of all the messages and attributes for the object will pop up. And when you mouse over a message name, a description of what it does appears taken directly from the Max reference documentation. Select the message, and Max creates a message box containing the message name already connected to the object's inlet.

The point is, even if you're really into Max, we think this stuff is going to make a difference for you. And if you could never really "get" Max, we think it's likely that the new version will lead you closer to mastery.

Not-so-Silly Little Things

Of course, no decent software upgrade is complete without a ton of little improvements, and Max 5 has more than its share. If you are really into the software, we hope you'll appreciate the many little things we've done to make Max a little less annoying. Here are a few, just picked at random.

1. The new patcher file format is designed to let you to save files for the preset object without fear that your preset won't work if you change the patch.

2. vst~ provides host sync to plug-ins

3. You no longer need to prepend a message with "symbol" in order to send it to a message box.

4. You can double-click on a search path listed in the file preferences window and it will show you where the path is on your hard drive.

5. You can edit the data in the pattrstorage window.

And how about two more bigger things:

1. Any movie, audio file, or image can be previewed directly inside the new File Browser, and then dragged onto the object where you want to use it.

2. poly~ distributes its subpatchers onto multiple processors, resulting in a substantial performance improvement in many cases

What We've Left Behind

As with any transition, not everything is "the same only better." I've told everyone who would listen that the timeline object was a dead end, and it is now history. I think the new musical time system, which I'll discuss in a future article, offers far more power and flexibility than the timeline, but it is not identical. And we are by no means finished with timeline-like things for the future -- but even to compare them to timeline offends me. We've also dropped the editing window in the detonate object and we're also not moving the env and envi objects to Max 5. I doubt many people will miss these things.

Old and New

Finally let's talk about compatibility, the dirty underbelly of any big software project.

At the present time, we're starting to work on ensuring that the vast majority of existing Max 4.x patches will work in Max 5 without any appreciable pain and suffering. After all, that wouldn't really do much for ease-of-use would it?

However, a few things are just not going to be possible to transfer to Max 5 unchanged. The main issue is external object compatibility. While most objects are going to work without any modification in Max 5, third-party user interface objects such as sliders and dials, and objects that display something in their own window will not work and will need to be rewritten completely. There really aren't very many of these objects, and developing new ones is now so much easier, we expect the trade-off will be worth it in the long run. We really needed to ditch the old UI object model to be able to do any of the cool new things we're doing.

Another thing that won't work is Pluggo plug-ins based on Max 4. These will need to be converted to a new format based on Max 5. Unfortunately, this new format is unlikely to be ready when Max 5 is first released. If your life revolves around plug-in development, you'll probably want to wait to upgrade until we change our plug-in support to work with the new core environment. Support for non-Pluggo VST plug-ins has improved in Max 5.

Anything written in Javascript to work in jsui or Java to work with mxj will work fine in Max 5. There's a new drawing model in Max 5 available from within Javascript that provides a number of improvements over the existing Sketch model, but Sketch is completely supported.

As I mentioned above, Max 5 has a new file format. It is entirely textual -- it's based on JSON which is a more readable version of XML -- and if you need to, you'll be able to look at a file and immediately see what everything means. It provides for Unicode character support, unlike the old format, which only allowed you to save comments in unicode if you checked a special box. Max 5 can also read and write files with long filenames (finally!) on both the Mac and Windows. However, we are not planning to export Max 4.x files from Max 5. Someone could probably write a converter fairly easily, but it probably won't be us.

What Lies Ahead

Over the next few months I'll be writing regular articles explaining more details about Max 5. I'll also keep you up to date on our progress as we move closer to a release. At this point, we are not planning any sort of public beta testing period, primarily because our documentation is still in the process of being revised and integrated. We also want to spend our time making the software better and more reliable, not answering questions about how it works. However, we're considering some alternative strategies for ensuring we've made Max 5 as compatible and reliable as possible when it is released.

Max 5 is a new beginning. It is really a wonderful testament to the growth of the Max community over the past twenty years that you've given us the opportunity to invest so much time and energy into this new version. I very much hope you will think our efforts will makes your creative life a little happier.