Puredata and Max/MSP are great, but programmed in a visual dataflow style rather than a source-code style. Imo that makes some things much more intuitive and other things really complex.
The visual dataflow style is especially good for interactive stuff, where you're taking inputs and running them through chains of synths and filters, but it gets really hairy if you want to do non-interactive composition. People use it for that too, but you end up with huge banks of delay lines to simulate control-flow constructs, which in other languages could've just been a for loop.
Yeah ! So much this. Iterations / branches / arrays ... in Max is pure nightmare. Supercollider is a breeze to work with hundreds / thousands of audio buffers and the multichannel / polyphonic capabilities are incredible. I found it very hard to build a stable complex patch in Pd / Max if you are not that much experienced with the opaque control flows.
> but you end up with huge banks of delay lines to simulate control-flow constructs
I'm not sure what you're referring to. Pd has a whole category of control objects for routing arbitrary message data. This includes branching and looping in zero logical time.
Have you used it? I usually don't use proprietary software but I've been thinking of giving it a go. Supposedly bitwig has a language as well but I haven't used it either
Bitwig uses JavaScript for MIDI controller scripting [1], then in version 3 they released The Grid [2] - which is a modular (but not low-level/basic DSP) visual environment allowing the creation of custom synths/effects. You can go deeper with Max for Live which is bundled with Ableton Live Suite. There is apparently a somewhat-hidden Ableton Python API. [3]
REAPER is probably the most-scriptable DAW of all, with an API using EEL, Lua, and/or Python. [4]
Miller Puckette originally created Max at IRCAM (Institut de Recherche et Coordination Acoustique/Musique) in 1985, which is now marketed by Cycling '74.
Then he later developed the open source Pure Data (PD) in the 90's, which also included real time signal processing features (flowing streams of high frequency audio over wires whose samples are at a much higher rate than the frame rate of the visual program's control signals).
Max/MSP and PS are both visual data flow programming languages, where data flows along wires between icons, but some data (like audio stream samples) flow much faster than others (like messages, logic, and control signals).
Cycling '74 Max later adapted Puckette's work on Pure Data and called it "Max/MSP", which stands for both "Max Signal Processing" and his initial "Miller Smith Puckette".
>Max is named after composer Max Mathews, and can be considered a descendant of his MUSIC language, though its graphical nature disguises that fact. Like most MUSIC-N languages, Max distinguishes between two levels of time: that of an event scheduler, and that of the DSP (this corresponds to the distinction between k-rate and a-rate processes in Csound, and control rate vs. audio rate in SuperCollider).
> flowing streams of high frequency audio over wires whose samples are at a much higher rate than the frame rate of the visual program's control signals
Pd's "control" classes are probably confusing to programmers coming from other computer music environments. There's no control rate in Pd.
The "control" classes (the ones without a tilde at the end of their name) send messages in zero logical time and may be triggered sporadically. Building diagrams out of them is like building an immediate-mode Rube Goldberg machine.
There are some conversion classes that allow control <-> signal object communication. Some of the control-to-signal classes do conversion at what you could call "control rate"-- e.g., they might compute a single value and copy it to the rest of the samples for output. Others do sub-sample accuracy bounded by the precision of floats (single or double as Pd can be compiled to use either).
If you're weird you can use [bang~] to emulate a control rate diagram-- it will literally output the "bang" message at each block which you can then feed to a downstream Rube Goldberg machine in order to do arbitrary message passing each block. But that's less ergonomic than just using signal objects which a) all send the same type of vector data and b) get automatically ordered by the graph builder and are therefore easier to read. (The irony being that signal diagrams generally deal with DSP, so the readable part of the diagram is the most conceptually complex and the simple stuff like branching or counting to 10 tends to end up looking like a plate of spaghetti.)
There's also overhead in the control message dispatch which would probably undo any imagined efficiency gains. Signal diagrams on the other hand get sorted into an array of function callbacks (as needed during runtime or editing time), so there's no chasing of pointers or type-checking to eat up cycles.
I've been using MaxMSP for a few years and I highly recommend it! There are tons of built in examples and pre-loaded modules. Their plugin and app store has a similar feel to Arduino's and also full of hundreds of free sketches by other users.
Opening someone else's sketch and playing around with the different components has been a great way for me to learn some of the more advanced features.
If you end up using it and making something cool, please share!
A proprietary but much more approachable and functional offshoot is Max/MSP.