Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

en.wikipedia.org

Post reply on HN
Print view View original

31–40 of 68 posts

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

#31

Post by whiddershins »

jcelerier wrote: post #20
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 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.

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

#32

Post by suyash »

sideb0ard wrote: post #26

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!)

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

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

#33

Post by trynewideas »

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…

> This kind of reinforces my point of the languages being only really suitable for simple patches

I can't parse whether or not this is a problem, and if so whether you're arguing that visual programming is bad or just something you don't like.

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

#34

Post by qmmmur »

AndrewUnmuted wrote: post #25
floatrock wrote: post #24

Earlier quoted context omitted.

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

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.

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

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

#35

Post by wwweston »

spacechild1 wrote: post #28
wwweston wrote: post #13

Earlier quoted context omitted.

With puredata, is it convenient to either: * write/script your own "objects"/nodes in some conventional programming language * abstract a "patch" into its own node (thus writing a node in pd itself)

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

Excellent, thank you!

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

#36

Post by jancsika »

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

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.

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

#37

Post by jcelerier »

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.

http://www.yuvalgerstein.com/ableton-live-started-out-as-a-h...

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

#38

Post by rectang »

qmmmur wrote: post #34
AndrewUnmuted wrote: post #25

Earlier quoted context omitted.

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.

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

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:

https://www.youtube.com/watch?v=aPh4Z3SioB8&t=29m25s

Is Max/MSP different?

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.

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

#39

Post by AndrewUnmuted »

qmmmur wrote: post #34
AndrewUnmuted wrote: post #25

Earlier quoted context omitted.

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.

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

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

#40

Post by TheOtherHobbes »

qmmmur wrote: post #18
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…

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

Post reply on HN