Max/MSP: A visual programming language for music and multimedia

Max and Pd are interesting languages. Quoting the original designer, Miller Puckette [0]:

"The design of Max breaks many of the rules of computer science orthodoxy, sometimes for reasons of practicality and sometimes of style."

Audio and control signals are both represented in the same canvas, but with substantially different semantics. Audio signals are roughly what you might expect if you are familiar with analog audio processing: plug one box into the next, and data is constantly flowing. The control signals are actually messages (think MIDI), and can have some counterintuitive semantics. For example: if a single message is sent to two different objects, then those two objects send a message to a third (diamond shape), the third object will be executed twice, despite all of this happening in the same logical time-step. Execution order also depends on the position of the objects in the canvas, IIRC.

The semantics are at least partially historical, because when Max was originally developed, real-time DSP wasn't available.

[0]: http://msp.ucsd.edu/Publications/dartmouth-reprint.dir/

Max is Max/MSP, where:

* MSP is an engine for generating/synthesizing/analyzing realtime audio which the user builds as a diagram in a GUI. The backend automatically sorts the diagram into a graph and generates the audio as the user builds the program. So by the end, the programmer has used their ears to measure whether the program can indeed compute audio for the diagram in realtime. (And the corresponding classes for signal computation are designed with soft realtime scheduling in mind.)

* Max is a general purpose programming language where the user creates and connects various branches of different Rube Goldberg machines together in a GUI. This appears superficially similar to DSP diagrams above. But each object in the chain can do anything from simple realtime appropriate math to doing file i/o while allocating large chunks of memory. There's no easy way to tell which of these Rube Goldberg objects are realtime safe. Plus one can iterate infinitely and recurse into already recursive chains of calls with ease. (The MSP engine prohibits recursion.)

Due to lack of constant aural feedback for Max diagrams, users typically keep a separate, erroneous mental model of all the Rube Goldberg machines in their short-term memory. In fact, most users practice a novel form of cryptography I call "Fresco-based write protection": the user keeps drawing and connecting more Rube Goldberg machines atop one another until their short-term memory becomes the only private key that can decode them. Given about 30 minutes for the frescoes to "dry," this technique is proven secure even against rubber hose attacks.

For maximum frustration, Max/MSP has objects which let the user hook Rube Goldberg machines up to a DSP graph, and vice versa. And I mean maximum frustration: while such inter-diagram connections give users functionality they wouldn't otherwise have, they also give users the false-confidence necessary to schedule a performance that ends up with that user staring at a silent laptop and muttering, "I don't understand, this worked fine on Tuesday."

Edit: clarification

> For example: if a single message is sent to two different objects, then those two objects send a message to a third (diamond shape), the third object will be executed twice, despite all of this happening in the same logical time-step.

That's not an accurate description of the language's semantics.

For example-- is the third object a unary or binary operator?

Also-- for a unary object in a proper flow-based language, what happens if that third object is a unary operator like `sin`? I think the language/frontend cannot let you make the connection because it doesn't make any sense (or you'd end up implicitly overwriting one of the values/vectors).

In a Max control chain you do get two outputs from two incoming connections to a unary operator. But then perhaps the programmer wanted to collect those two values into a two-item list and trigger that further down the chain. If they practiced "Fresco-based write protection" as they were trained, the diagram is encoded as spaghetti and we can never know for sure. :)

These are valid criticisms (although parsing max patches is very easy as they are just json files). However, I think you're missing the point. The point of Max is to be one notch away from something like Ableton - a language and methodology for programming your own routines, patterns and at the lowesr level DSP algorithms (something that gen~ has facilitated nicely). You might even write your own objects in c++ if the need for functionality grows. I'd say I'm an expert in Max having spent considerable time in it developing applications and doing research and the trade off of not having those 'traditional' software engineering and computing tools is that you can work in an incredibly dirty and ad hoc way. At the end of the day it's a tool designed with creative goals in mind and the idea of unit testing, deploying, etc etc are not paramount to people's practice mostly. They just want to develop ideas fast in fairly stable real-time environment.

> The point of Max is to be one notch away from something like Ableton

ahaha, when you think that Ableton was born from Max :)