Reversing Workflow in Max

by Clint on May 8th 2011

@cycling74 recently tweeted asking "What is the best #MaxMSP advice you've ever heard?". A few good responses. I like "use route inside sub-patches so that they only need one inlet" for example.

Here's one from me. When starting a new project in max I often find it useful to reverse the workflow and start in presentation mode.

The natural tendency for me (and most people I think) is to start with a source, either midi or audio or video signal and start moving it through a series of steps towards the idea in my head. So the start of a patch/device that uses midi would be to use edit mode and add a notein or midiin object. Then you'd build and build and build on top of it. Then FINALLY you'd add things to presentation mode and make an interface out of it to control it.

I think this is a fairly common approach. When making a simple patch I would call a "utility" or a simple proof of concept to figure out how something is done, that's still the way I'd approach it.

But when starting a new complete complex project, or instrument, the reverse approach often gets better results.

When starting on a new instrument, try starting with the interface. I don't mean to focus on the look of it right away. You can mess with that after it's done as normal. But i mean start your complex device by answering some questions about what it is that is required to use it in the end. I would add dials, faders, number boxes and so on to build a rough look into what the thing should do when complete.

From there I start answering questions about it. What is needed to make this knob do that? What is needed to make this button change that? Then I create sub patchers under each interface knob to answer those questions.

I think this is a backwards way of working for most people. You start with the goal, then work backwards answering questions about how you'd get there. Why would you try this approach? For me, it forces some sort of logic into the patch that makes for much more organized and readable code in the end. Rather than a stitched up mess of things I built to figure out how to get from A to B, I end up with encapsulated patches that show me why A turns into B.

May not work for everyone. And like I said for a simple utility like "transpose all incoming midi notes" I wouldn't bother trying to work backwards. But for a complex patch, give it a try. Sometimes it's easier to reverse engineer your own idea this way than stare at a blank max window and wonder how to get started.


blog comments powered by Disqus