Max/MSP: A visual programming language for music and multimedia • Hacker News Board

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

#41

Post by qmmmur » Mon, Feb 17, 2020, 9:06 PM UTC

floatrock wrote: post #24

jancsika wrote: post #14

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 f…

> 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 p…

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.

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

#42

Post by dhosek » Mon, Feb 17, 2020, 9:07 PM UTC

jcelerier wrote: post #19

pmoriarty wrote: post #17

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…

> 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. c'mon, the first dataflow languages date from the 60s, that's barely after the first textual PLs - see eg https://www.youtube.com/watch?v=QQhVQ1UG6aM > There's no way to harness the incredible power of text editors like vim or emacs. have fun showing most art stu…

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

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

#43

Post by qmmmur » Mon, Feb 17, 2020, 9:13 PM UTC

AndrewUnmuted wrote: post #39

qmmmur wrote: post #34

Earlier quoted context omitted.

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

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 ye…

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

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

#44

Post by qmmmur » Mon, Feb 17, 2020, 9:14 PM UTC

jancsika wrote: post #16

tayistay wrote: post #12

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 a…

> 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…

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.

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

#45

Post by qmmmur » Mon, Feb 17, 2020, 9:18 PM UTC

TheOtherHobbes wrote: post #40

qmmmur wrote: post #18

Earlier quoted context omitted.

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 th…

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, prependi…

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.

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

#46

Post by qmmmur » Mon, Feb 17, 2020, 9:18 PM UTC

whiddershins wrote: post #31

jcelerier wrote: post #20

Earlier quoted context omitted.

> The point of Max is to be one notch away from something like Ableton ahaha, when you think that Ableton was born from Max :)

That doesn’t sound right.

Ableton was a max patch once.

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

#47

Post by qmmmur » Mon, Feb 17, 2020, 9:19 PM UTC

pier25 wrote: post #23

Also check out GEN which was recently added to Max. 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.

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

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

#48

Post by qmmmur » Mon, Feb 17, 2020, 9:21 PM UTC

pmoriarty wrote: post #21

qmmmur wrote: post #18

Earlier quoted context omitted.

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 th…

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 b…

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.

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

#49

Post by strbean » Mon, Feb 17, 2020, 9:48 PM UTC

strbean wrote: post #30

raptorraver wrote: post #3

Opensource alternative Pure Data is also worth mentioning: https://puredata.info/

There was a cool web implementation back in the day... 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...

Oof, how does this comment garner a drive-by downvote?

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

#50

Post by AndrewUnmuted » Mon, Feb 17, 2020, 10:05 PM UTC

qmmmur wrote: post #43

AndrewUnmuted wrote: post #39

Earlier quoted context omitted.

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 ye…

> 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…

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