Max is Max/MSP, where:<p>* 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.)<p>* 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.)<p>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.<p>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."<p>Edit: clarification
I've been using MaxMsp for a few years now, and I've been writing software for much longer. When I'm using Max (for audio and midi), it does not strike me as a "visual programming language", nor do I feel like I'm writing software. It strikes me as a modular environment like Reaktor or VCV rack, but one step closer to the "metal".<p>And in that space, I think it works wonders. I initially got into Max because I had a lot of ideas for midi sequencing that I couldn't execute with more traditional tools. Initially I tried writing it by hand in C++ (which I did to an extent), but it became tiresome.<p>Max was a breath of fresh air. I was building sequencers, clock dividers, sequential switches, and all types of bespoke tools very quickly. A background in software definitely helped, but it was still a quick learn. Additionally, I can sync with DAW's, grab data off of IAC busses, and map controls to Midi controllers very easily. All things I'm happy to not concentrate on while being creative.<p>I don't have as much experience with the MSP (audio) side, but I have built some loopers and granular inspired patches.
Max and Pd are interesting languages. Quoting the original designer, Miller Puckette [0]:<p>"The design of Max breaks many of the rules of computer science orthodoxy, sometimes for reasons of practicality and sometimes of style."<p>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.<p>The semantics are at least partially historical, because when Max was originally developed, real-time DSP wasn't available.<p>[0]: <a href="http://msp.ucsd.edu/Publications/dartmouth-reprint.dir/" rel="nofollow">http://msp.ucsd.edu/Publications/dartmouth-reprint.dir/</a>
Opensource alternative Pure Data is also worth mentioning: <a href="https://puredata.info/" rel="nofollow">https://puredata.info/</a>
Also check out GEN which was recently added to Max.<p><a href="https://www.youtube.com/watch?v=eDYs2UZzhI4" rel="nofollow">https://www.youtube.com/watch?v=eDYs2UZzhI4</a><p>It's a low level DSP engine that is already used in Ableton Live and embedded systems for modular synths.
If you're in SF in march and interested in Max/MSP, my conf/music festival, Algorithmic Art Assembly, has a workshop on Creating Digital Instruments with Max/MSP - <a href="https://aaassembly.org/workshops/" rel="nofollow">https://aaassembly.org/workshops/</a> (conf also features Miller Puckette, Curtis Roads and many more!)
If anyone's interested - I'm working on ossia score (<a href="https://ossia.io" rel="nofollow">https://ossia.io</a> ; <a href="https://github.com/OSSIA/score" rel="nofollow">https://github.com/OSSIA/score</a>) which is a bit like Max & PD, but the dataflow is integrated directly in the timeline which allows for better expressibility of evolution of time in the artwork.
I have a real problem with visual languages like Max and PureData (and all the other visual languages I've ever seen).<p>They seem like a good idea, and might be fine for computer-phobic people just starting to be introduced to programming, but whenever one tries to make anything even a little complex in them they inevitably become a mess of spaghetti-code.<p>Languages like these also don't have the almost hundred years of research and effort in to creating an ecosystem around them like text-based languages do.<p>There's no way to grep, diff or sed the source while remaining on the visual level. There's no way to harness the incredible power of text editors like vim or emacs. When there are lots of connections, determining what's going where becomes difficult to determine, though at least they do have some modularity. Debugging and tracing facilities tend to be minimal to non-existent. There are no static analysis tools, refactoring tools, fuzzing tools, unit-testing tools, or behavior-driven testing tools, no way to design by contract.<p>These things are in their own little backwater. They look cool, and are easy to start with, but that's about it.
For those interested in learning formally, there is an online course in Max/MSP available through the Kadenze online school:<p><a href="https://www.kadenze.com/courses/programming-max-structuring-interactive-software-for-digital-arts-i/info" rel="nofollow">https://www.kadenze.com/courses/programming-max-structuring-...</a>
I don't know if you can use this with the Max standalone version, but here are plenty of devices for Max4Live (Ableton Live's integrated version of Max): <a href="https://maxforlive.com/" rel="nofollow">https://maxforlive.com/</a>
I've used PureData a bit and found the UI rather minimalist. VCV Rack has a UI that's considerably more fun, but from a programming perspective, most modules are quirky rather than orthogonal and general-purpose. How does Max compare?
Opcode did so much great stuff: their sequencer Vision was so much more immediate and intuitive than anything else I ever tried. It was a tragedy when Gibson bought and gutted them.
Anyone familiar with music design languages—-how do this and others mentioned in comments (supercollider, puredata) compare with Ruby/midi based sonic-pi?