* 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."
> 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.
Not to mention, it doesn't have to work like this... There are people, and I say this unashamedely, like myself that are experts in how Max works from its lowest level systems such as the scheduler to basic concepts such as order of execution. It is a great language for putting together robust performance software as much as it is a playground for heinous DSP graphs which can break, splutter and fail. A lot of people here are complaining that Max is a bad language because you can't grep/sed/awk it or that it doesn't have unit testing but they're totally missing the point.
> but honestly this bit describes every piece of sufficiently complex software I've worked on.
Just to be clear: the word "atop" is being used literally here in a way that doesn't hold for text-based languages.
Your frustration: "What does z() do, and why is it calling flarg() twice?"
My frustration v0.1: "What does z() do, and why is it calling flarg() twice?"
clicks and drags an object to reveal another Fresco
My frustration v0.2: "What does z() do, why is it calling flarg() twice, and why are there 7 instances of flarg pasted atop one another with internal non-local connections which trigger stack-overflow protection every time z gets called? Also, why is there a zero-width spacer between the 'z' and the '()' which, while somehow syntactically correct, causes 'z' not to get called? Also, why does the text editor require one to click and drag a line from 'z' to the '()' in order to get rid of the zero-width spacer in order to actually call the function?"
Edit: I'm sure you can find similar weirdness in a text-based language. Perhaps if one made a contract that they're going to use a global setter variable in every function of a Javascript program which will mutate some global state. That would be bad. But you really have to work to do that whereas the natural tendency in Max is to wrap an object-chain back atop itself to create unreadable spaghetti as one builds a prototype.
In Pure Data, the file format describes a directed graph of objects. It's not just freeform. Here's part of a presentation on "Dataflow Programming" talking through that graph:
Pure Data is Dataflow-ish programming language. It's fine for Dataflow nodes to be written in another language so long as the node is self contained — that's the essence of "Hybrid Dataflow".
Pd has some global state so it's not pure Dataflow, but from what I can tell that state is not what the rant earlier is complaining about in the context of Max/MSP.
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.
> 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.
> 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.
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.
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.
I teach Max at a college level currently. The Rube Goldberg machines you speak of result from over engineering and the weird philosophy Cycling 74 has of always having new versions of Max be backwards compatible.
However after you spend a good amount of time you start to be able to avoid these higher-level over engineered mini libraries and be able to use lower level operators to achieve exactly what you want and nothing more. After you build up your own library of modules all is well.
But I do agree with your point. I've even been creating my own counters lately because even simple things like the counter "object" in Max are so bloated.
Bravo! If you enjoyed that anti-Max performance art trolling, but thought it wasn't spectacularly hyperbolic and sociopathic enough, I recommend looking up some of the classic flames on the nettime mailing list by Netochka Nezvanova aka "NN" aka "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp"!
>Netochka Nezvanova is the pseudonym used by the author(s) of nato.0+55+3d, a real-time, modular, video and multi-media processing environment. Alternate aliases include "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp". The name itself is adopted from the main character of Fyodor Dostoyevsky's first novel Netochka Nezvanova (1849) and translates as "nameless nobody."
She (or he or they or it) were the author of the NATO.0+55+3d set of extensions for Max, which predated Jitter:
>NATO.0+55+3d was an application software for realtime video and graphics, released by 0f0003 Maschinenkunst and the Netochka Nezvanova collective in 1999 for the classic Mac OS operating system.
Behold this beautiful example of fresco-based write protection:
>>>What’s your connection with the notorious ‘nato’ software?
>Nato was the first software that gave me the push to start exploring the live visual world.. before that I did video art making analogue video, and imposing graphics with amiga. Then multimedia and internet projects seemed to offer more possibilities and not until finding Nato did I return to pure video. Fiftyfifty.org was distributing Nato in the beginning, and invited Netoschka Nezvanova various times to Barcelona, my connection with Nato was quite close but now I’m using the “enemy” software Jitter and sometimes Isadora. Jitter is far more complicated and more made for engineers/programmers than Nato, which was basically a video object library for max/msp, and more fun – it seemed always so fragile, and easy to lose.
DonHopkins on Oct 6, 2014 | parent | favorite | on: "Open Source is awful in many ways, and people sho...
Does anybody remember the nettime mailing list, and the amazing ascii graphics code-poetry performance art trolling (and excellent personalized customer support) by Netochka Nezvanova aka NN aka antiorp aka integer aka =cw4t7abs aka m2zk!n3nkunzt aka punktprotokol aka 0f0003, the brilliant yet sociopathic developer of nato.0+55+3d for Max? Now THAT was some spectacular trolling (and spectacular software).
Netochka Nezvanova is a software programmer, radical artist and online troublemaker. But is she for real?
The name Netochka Nezvanova is a pseudonym borrowed from the main character of Fyodor Dostoevski’s first novel; it translates loosely as “nameless nobody.” Her fans, her critics, her customers and her victims alike refer to her as a “being” or an “entity.” The rumors and speculation about her range all over the map. Is she one person with multiple identities? A female New Zealander artist, a male Icelander musician or an Eastern European collective conspiracy? The mystery only propagates her legend.
Cramer, Florian. (2005) "Software dystopia: Netochka Nezvanova - Code as cult" in Words Made Flesh: Code, Culture, Imagination, Chapter 4, Automatisms and Their Constraints. Rotterdam: Piet Zwart Institute.
Empire = body.
hensz nn - simply.SUPERIOR
per chansz auss! ‘reazon‘ nn = regardz geert lovink + h!z !lk
az ultra outdatd + p!t!fl pre.90.z ueztern kap!tal!zt buffoonz
ent!tl!ng u korporat fasc!ztz = haz b!n 01 error ov zortz on m! part.
[ma!z ! = z!mpl! ador faz!on]
geert lovink + ekxtra 1 d!menz!onl kr!!!!ketz [e.g. dze ultra unevntfl \
borrrrrrr!ng andreas broeckmann. alex galloway etc]
= do not dze konzt!tuz!on pozez 2 komput dze teor!e much
elsz akt!vat 01 lf+ !nundaz!e.
jetzt ! = return 2 z!p!ng tea + !zolat!ng m! celllz 4rom ur funerl.
vr!!endl!.nn
ventuze.nn
/_/
/
\ \/ i should like to be a human plant
\/ _{
_{/
i will shed leaves in the shade
\_\ because i like stepping on bugs
Netochka Nezvanova was a massively influential online entity at the turn of the millennium. An evolution of various internet monikers, among them m2zk!n3nkunzt, inte.ger, and antiorp, Nezvanova has collectively been credited for writing a number of early real-time audiovisual and graphics applications. She was also a prolific and divisive presence on email lists, employing trolling as a form of propaganda and as a tool for creative disruption—though, at times, users adopting the moniker also engaged in harassment and other destructive behaviors.
Among her most well-known pieces of software are the data visualization application m9ndfukc.0+99, which runs within a custom browser created for the app, and the realtime audiovisual manipulation tool, NATO.0+55+3d (which would later be repurposed as Jitter by Cycling ’74). Using data as raw material, these applications mined the artistic potential of noise, randomness, and the unexpected.
In spite of (or perhaps in service to) the many pieces of software attributed to this anonymous online entity, the singular lasting impression of Nezvanova has been rooted in her seriously anarchic attitude—in the elusive, yet public, persona that she carefully crafted as a hybrid, internet-based act of performance art.
Whether trailing code poetry across nettime mailing lists and online forums, or distributing software licenses at contentious fees to academics, Nezvanova was using information architecture itself as a medium. Often times, she would forgo the legibility of clean software design to produce unpredictable outcomes, and even reveal discrete truths.
"I have not been thrown off a mailing list.
I have been illegally transformed into a yellow flower.
A young girl one day found me, and with half closed eyes whispered:
Perfection,
Today you've peered in my direction."
—Netochka Nezvanova
Oh, it was so futuristic! I was young and easily impressed. It was the last time for me that the present felt like a prelude to the future. A few years later and the progress of time meant little more than a constant dribble of new codepoints getting added to the emoji set.
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.
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.
> 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. :)
Sorry, I should have specified that the third object is a unary operator (was thinking just print). The point is that it can execute something twice, and that differs from a proper flow-based language.
The main point is that the semantics are, shall we say, interesting.
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.
Seconding this: PureData is very good - used it throughout my second and third years of university to create soundscapes and scores. A little DSP knowledge is required to get really good, but very rewarding once you get the hang of it.
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...
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.
* there are various extensions for embedding python or lua. For the latter, checkout pdlua or ofelia.
* yes, they are called abstractions. They also have a nice feature called “graph on parent“, where part of the abstraction's canvas will appear on the parent canvas.
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/ (conf also features Miller Puckette, Curtis Roads and many more!)
If anyone's interested - I'm working on ossia score (https://ossia.io ; 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.
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.
> 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 harness the incredible power of text editors like vim or emacs.
have fun showing most art students how to use vim or emacs :p just typing a few commands in a console to build a project is already a galore from past teaching experience.
Thanks for that link to the wonderful video of Alan Kay showing a demo of GRaIL recorded in 1968!
Here's a film of another early system called "PIXIE" for editing graphs and circuit diagrams by Neil Wiseman, Lemke and Hiles from 1969, showing the first know implementation of what I call "pie menus". The librarian David Chapman at the Cambridge University was quite helpful and generous enough to arrange for that film to be transferred to video and posted on their site. (Librarians rock, and Cambridge University has an excellent library! ;) It hasn't widely seen, and was only recently published online!
>This film demonstrates an early graphical user interface in use. It was made in 1969 to accompany a paper entitled “PIXIE: a new approach to graphical man-machine communication” presented at the 1969 CAD Conference held in Southampton.
>The classic 1969 “PIXIE” paper by Neil Wiseman, Lemke, and Hiles had the first mention of circular menus, which was referenced in Newman and Sproull’s 1979 seminal book “Principles of Interactive Computer Graphics”. The “lightbuttons” were apparently target area based (selected “by pointing at one of them”), unlike pie menus which are based purely on the direction of the gesture, resulting in a large wedge shaped target area extending to the screen edge, not just the small rectangular area of the “lightbutton” label:
>PIXIE: A New Approach to Graphical Man-Machine Communication
>Wiseman, N.E., Lemke, H.U. & Hiles, J.O. (1969) PIXIE: A New Approach to Graphical Man-Machine Communication, Proceedings of 1969 CAD Conference Southampton, IEEE Conference Publication 51, 463–471.
>"The control lightbuttons which are used frequently within a mode to carry out a sequence of operations. These buttons are displayed around the tracking cross and move about with it so that the user’s hand is always close to these buttons when he needs them. To avoid clustering a large number of control buttons around the tracking cross, it is arranged that only buttons for those actions which are legal at any given time are displayed and also that the user may select different sets of legal buttons by pointing at one of them (which acts as a sort of rotating switch for the rest)."
> have fun showing most art students how to use vim or emacs :p just typing a few commands in a console to build a project is already a galore from past teaching experience.
Back in the 80s, I used to teach LaTeX workshops, primarily to math department secretaries. These were usually given in a university's computer lab. At one such lab, the staff had decided that the students should use vi. The problem was that the terminals were such that hitting any of the arrow keys would be interpreted by vi as delete the current paragraph irrevocably. After one morning of frustrated students, I switched everyone to emacs. We didn't use a fraction of emacs's power, but at least the arrow keys worked.
I hate to be the one to say it, but vim and emacs are basically just programmable card punch machine emulators. Of course Emacs is obviously the best card punch machine emulator, by far, though. ;)
Some of those chaos just happens, because just like in textual languages, many people write monoliths instead of making use of the modular tools made available to them.
Most visual languages that aren't toys, do have search capabilities, visual debuggers, and most importantly the ability to package code blocks into modular units.
Unreal's Blueprint tooling is quite powerful, and several games have been written like 99% in Blueprint.
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.
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.
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.
The lack of tools isn't the problem. The problem is that Max reimplements basic CS concepts badly, eccentrically, and unintuitively, for no real benefit, while adding a huge extra cognitive load.
Max for Live highlights why this is bad. If you can find the unofficial docs, it's much easier to access the LOM using Python - or pretty much any standard language - than to do all the string/list/symbol splitting, prepending, filtering, combining, and so on you're forced to do to make anything non-trivial happen in Max itself.
I think there's an open niche between Max, which is just plain weird and difficult in too many ways, and the low-level world of Juce and C++.
I'd love to see a scriptable industry standard plug-in architecture with a super-easy "just works" set-up for graphics, DSP, MIDI and timing, based on a modern high-level language, but also fast.
WebAudio is somewhere in that niche, but - aside from being browser dependent - it's still too close to the metal for most users. Some of the plug-in construction kits are too high level. Faust is good but still very specialised.
I suspect there's a sweet spot between the extremes, and it's not currently been catered to.
Again, you're missing the point. Max and pd were developed for composers and musicians to execute live performances of institutionalised academic music (as well as its long history of connections to IRCAM in Paris). It does that perfectly.
Reaktor does it better and is simpler to learn in my opinion. Max tries to be both high level and low level, which makes it more a tool for engineers than artists.
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/
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?
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.
Max and ~pd are roughly equivalent from a programming perspective. They have different ecosystems though, with a lot of overlap, but also with a bunch of differences.
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?
* 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