
Max/MSP: A visual programming language for music and multimedia - zaiste
https://en.wikipedia.org/wiki/Max_(software)
======
jancsika
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

~~~
floatrock
> users typically keep a separate, erroneous mental model of all the Rube
> Goldberg machines in their short-term memory... 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.

It really was a cute rant (we've all been there where we've hated using
something _that_ much!), but honestly this bit describes every piece of
sufficiently complex software I've worked on. Not sure about you, but I poke
my coworkers all the time to ask "hey, can you explain what this bit of
business logic does again? I think I need to reuse it for this new feature..."
Maybe Max just needs a unit testing framework.

~~~
AndrewUnmuted
lol unit testing? Max/MSP objects are just enormous json blobs. They have much
bigger problems with that language than unit testing.

People interested in musical programming should investigate SuperCollider and
completely bypass Max/MSP. It’s terrible software.

~~~
qmmmur
The object connections are described in json but the objects themselves are
c++.

~~~
AndrewUnmuted
Yes, that is technically true. A more objectively correct statement on my part
would have been, "Max patches are JSON blobs."

But let's be real: it's highly dubious software, exploiting the tired and
inefficient trope of the noodly "patch connections" approach made famous by
modular synth folks. The sound engine sucks, even with the new updates made
recently. The new versions are made using the JUCE framework, and yet it has
no Linux support. WTF? Good luck doing anything low-latency, on any platform,
using any kind of hardware. Seriously, last time I tried to agonize with
Max/MSP, that shit would start crackling at 48k and a block size of 192,
that's absurdly poor performance for any sort of "modern" audio software.

Max/MSP is something made to take advantage of "computer musicians" and "audio
engineers" who know very little about the actual computing platforms they
continue to exploit. These people have become decidedly easy to trick, they
simply don't approach their own so-called "craft" with the amount of
skepticism they must have in order to continue to practice that craft.

~~~
qmmmur
> exploiting the tired and inefficient trope of the noodly "patch connections"

That's the whole point. pd works the same way and so does vcvrack among more
localised tools like Reaktor.

> The new versions are made using the JUCE framework, and yet it has no Linux
> support. WTF?

I don't have any love for JUCE but you are naive to think that its as easy as
setting a new compile target and pressing go. Max is for profit and they need
to target the most salient customers. Forget how little the percentage of
people is that use Linux - you are aiming this product at a niche of niche
people already. Be realistic here if you're own money was at stake.

> Good luck doing anything low-latency, on any platform, using any kind of
> hardware. Seriously, last time I tried to agonize with Max/MSP, that shit
> would start crackling at 48k and a block size of 192, that's absurdly poor
> performance for any sort of "modern" audio software.

I can't say I've had as much problems as you. I have a friend whose work has
to be as low latency as possible (so that onset detectors are working really
fast) and his system is running somewhere at 16/32 for vector size. The
processing after this is non-trivial also.

I'd be curious to know what your professional use of Max is as you seem to
have an incredibly aggressive attitude to the software, how its made and the
people that use it.

~~~
AndrewUnmuted
> Max is for profit and they need to target the most salient customers.

The problem with this is that...

> professional use of Max

... surely, you jest.

This software is not stable enough, useful enough, nor performant enough to be
used in professional settings, outside of perhaps some of the "multimedia
performance" buffoonery of people like Carsten Nicolai.

One could not reasonably use Max/MSP for scientific or academic purposes, for
anything where precision was required. There is are so many useless GUI/state
management operations being performed by the sound engine that it makes it an
unreliable tool.

Contrast this with Max's FOSS cousin pD, the highly performant SuperCollider,
ChucK, or Csound even! It's a blow-out - Max/MSP is the worst-performing, has
the least imaginative and least innovative approaches, and doesn't really do
much at all in the way of refactoring for performance or for broad
compatibility with other software/hardware. Its community is the least-
knowledgeable and contributes the least - by far - to the broader computer
music community.

I had this Max/MSP nonsense thrown at me all throughout my collegiate
education. I was always able to easily convince people I didn't need that
specific, useless, proprietary software, to do my work. But it was a constant
uphill battle I had to fight. Because all Max/MSP did was entrench itself in
areas of the audio technology world that did not know better.

It's terrible software, designed with a terrible software development
ideology, and made popular for all the wrong reasons.

~~~
tayistay
Why do you find Pd so much better?

FWIW, Radiohead used Max/MSP live IIRC. Aphex Twin has used it. Neither are
"multimedia performance buffoonery". Though I love your characterization
because I've been subjected to plenty of said buffoonery.

~~~
sunjiroaoul
For us plebes, the FOSS makes pd great. Backwards compatibility is nice,
resurrecting 10 year old patches has never been a problem for me.

I suspect being successful musicians, cycling74 has an interest in getting
their product into your rig. I bet Johnny Greenwood gets custom objects if he
calls them up.

------
H1Supreme
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".

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.

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.

I don't have as much experience with the MSP (audio) side, but I have built
some loopers and granular inspired patches.

------
tayistay
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/](http://msp.ucsd.edu/Publications/dartmouth-reprint.dir/)

~~~
jancsika
> 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. :)

~~~
qmmmur
I mean, this kind of comment really only comes from someone who has never used
the language in any kind of depth. Whether or not the object triggers twice
depends on type of object as you pointed out, ordering of inputs forgetting
whether or not two executions is perhaps intended.

~~~
tayistay
Proving my main point--that the semantics are interesting--by way of nitpick
and ad hominem.

------
raptorraver
Opensource alternative Pure Data is also worth mentioning:
[https://puredata.info/](https://puredata.info/)

~~~
strbean
There was a cool web implementation back in the day...

[https://github.com/sebpiq/WebPd](https://github.com/sebpiq/WebPd)

Looks like the creator is gearing up to pump new life into the project (as of
11 days ago!). In the issue linked at the top of the README, he bemoans the
fact that he hasn't really had any other contributors. If anyone is looking
for an interesting project...

~~~
jancsika
If I had to guess, big blockers would be:

1\. webpd doesn't have a GUI editor, so you cannot leverage the browser to
prototype new ideas (or edit old ones). With that ability webpd would be like
a codepen for audio and therefore garner a lot more interest.

2\. Pd's gui logic mostly happens inside the audio engine which is coded in C.
It's a huge hairball of code that's a pain to work with.

3\. Pd's GUI paridigm is having multiple toplevel windows like the old Gimp
interface. That's a pain to use in Pd, but it's especially a pain to try
porting that to a browser. An HTML5 editor/display needs to be much less
complicated than motif in a Linux window manager.

I've been thinking about doing parallel work on a single-app style interface
for Purr Data and shipping it with a feature flag. (Parallel as in not
upsetting the current UI.) There has been some interest in such a project for
GSoC, but it's a beast of a project with lots of little pain points and detail
work to get it right.

------
pier25
Also check out GEN which was recently added to Max.

[https://www.youtube.com/watch?v=eDYs2UZzhI4](https://www.youtube.com/watch?v=eDYs2UZzhI4)

It's a low level DSP engine that is already used in Ableton Live and embedded
systems for modular synths.

~~~
qmmmur
I absolutely love gen~. Graham Wakefield's software is all super interesting.
His research centre at UoY is also very curious.

------
sideb0ard
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 -
[https://aaassembly.org/workshops/](https://aaassembly.org/workshops/) (conf
also features Miller Puckette, Curtis Roads and many more!)

~~~
suyash
That's neat, I live in SF and would love to submit my proposal for this event
on AI & Music possible?

------
jcelerier
If anyone's interested - I'm working on ossia score
([https://ossia.io](https://ossia.io) ;
[https://github.com/OSSIA/score](https://github.com/OSSIA/score)) 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.

------
pmoriarty
I have a real problem with visual languages like Max and PureData (and all the
other visual languages I've ever seen).

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.

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.

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.

These things are in their own little backwater. They look cool, and are easy
to start with, but that's about it.

~~~
qmmmur
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.

~~~
pmoriarty
This kind of reinforces my point of the languages being only really suitable
for simple patches, as the more complex they get the more they'll need things
like sophisticated debugging facilities, testing, tracing, etc to figure out
what's going on, why things work the way they do or why they break when they
don't.

As for them being just JSON files, that doesn't really help because these
languages aren't designed to be programmed on the JSON level. They're designed
to be programmed visually. Having a JSON file you can edit doesn't help any
more than having an XML file of a Word document. You're not going to be
editing your Word document using the raw XML. You need a word processor like
Word itself or Libreoffice to make sense of it and edit it in any kind of
meaningful way.

The potential is there, of course, to build text tools around manipulating the
raw JSON that would be Max-aware, but that would break Max's visual paradigm
and then you might as use a traditional text-oriented language to begin with.

~~~
qmmmur
If you have Max installed I'm happy to send you incredibly complicated DSP and
musical problems solved visually and cleanly. Open your mind for a second and
realise that musicians needs are almost entirely different to software
engineer's in a language.

------
JoeDaDude
For those interested in learning formally, there is an online course in
Max/MSP available through the Kadenze online school:

[https://www.kadenze.com/courses/programming-max-
structuring-...](https://www.kadenze.com/courses/programming-max-structuring-
interactive-software-for-digital-arts-i/info)

------
_def
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):
[https://maxforlive.com/](https://maxforlive.com/)

------
skybrian
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?

~~~
gmueckl
VCV Rack is firmly in the Eurorack tradition, which has an enormous amount of
deliberate quirkiness to inspire experimentation and new sounds. Max is pretty
a graphical programming language with a focus on signal processing, but a
scope that goes considerably beyond that.

------
Doctor_Fegg
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.

------
techbio
Anyone familiar with music design languages—-how do this and others mentioned
in comments (supercollider, puredata) compare with Ruby/midi based sonic-pi?

------
billfruit
Does it do rhythm heavy scores with regular drum beats etc?

~~~
jm547ster
It can, however you’ll have to build your own sequencers or find other
people’s work to cobble together

