This isn’t entirely on-topic, and it’s a bit negative, sorry about that!

Max patches just don’t play well with version control, and specifically git. It really needs a human readable file format that is diff friendly.

git is obtuse, arcane and frequently annoying. But it’s also magic.

It’s like a secret world of (almost) every piece of computer code ever written, and (almost) every change to that code ever made, and those of us that use it end up with small pieces of that vast data set on our computer. git is the fabric (or medium) of modern coding (and GitHub the social fabric).

I think Cycling 74 need to develop a way to tap into that magic. In someways I really like visual programming, especially for signal processing, though I go crazy and swear of it whenever I need to refactor. What I would love is hybrid approach, human editable text for when that’s appropriate (and for version control), but graphical for when that’s best.

3 Likes

Isn’t that what the js, node, and gen objects are for?

Paging @darwingrosse

3 Likes

uh, on my phone r/n but isn’t recent .maxpat format just .JSON? (or is this a special option at save time I forget)

[https://github.com/CNMAT/OSC/blob/master/Applications/MaxMSP/examples/UDPEcho.maxpat]

human-readable, not so much

1 Like

Not a Max person myself, but puredata patch files are somewhat human-readable, and now you’ve got me thinking about how tricky it would be to build a simple graphical puredata diff visualiser which could be added to git… I can imagine a few different options for how it might work or look, but think that it might be quite a UI challenge to make such a thing practical and useful.

2 Likes

As far as visual patchers go, pretty damn readable though the connections are pretty difficult to follow. Let me know if you come up with that visual patcher–though Pure-Data doesn’t need one as bad since it’s free :slight_smile: EDIT: actually i take that back, it would be rad to view patches from a web UI

mfoster@cyperus ~ $ cat Dev/cyperus/test/test_osc.pd 
#N canvas 3832 29 2110 2109 10;
#X msg 22 40 connect localhost 97211;
#X msg 113 72 disconnect;
#X obj 22 133 netsend -u -b;
#X floatatom 22 229 5 0 0 0 - - -;
#X obj 73 229 print;
#X obj 388 575 list trim;
#X obj 385 547 list prepend send;
#X obj 228 72 oscformat cyperus list mains;
#X obj 228 41 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 22 308 netreceive -u -b 97217;
#X obj 22 331 oscparse;
#X obj 22 354 list trim;
#X obj 22 400 print;
#X text 261 40 /cyperus/list/mains;
#X obj 471 109 oscformat cyperus add bus;
#X msg 467 28 list / main in out;
#X obj 705 368 print;
#X msg 684 20 list / 0;
#X obj 696 98 oscformat cyperus list buses;
#X connect 0 0 2 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 2 0 4 0;
#X connect 5 0 2 0;
#X connect 6 0 5 0;
#X connect 7 0 6 0;
#X connect 8 0 7 0;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 11 0 12 0;
#X connect 14 0 6 0;
#X connect 15 0 14 0;
#X connect 17 0 18 0;
#X connect 18 0 16 0;
#X connect 18 0 6 0;
1 Like

It’s a fair point. If you can’t follow the flow control, the simple fact that it’s a text format doesn’t really do much for you.

1 Like

Not just a text format, but also something that is diff-able. If it ends up reordering the JSON file it’s not that helpful.

Bonus points for visually highlighting the difference between two patches… (and when I say bonus points, I mean a lot of bonus points).

2 Likes

I think the differences between textual and visual programming paradigms are vast, and version control is only the tip of the iceberg. I’m pretty sure that visual programming isn’t going to serve the git domain very well (for example, spatial changes in a patch are hostile to diff-oriented VC in a fundamental way), so I doubt there is magic available to be tapped.

Any version control is super for saving complete versions of patches, but I’ve not seen it successfully used beyond that.

[ddg]

5 Likes

And there you have it. This is the main reason why a lot of folks have moved on.

Ihm, I dunno, I can imagine a patcher format that saves the graph and order of operations separately from visual layout. Can also imagine using graph-layout algos to automatically build a visual layout that is at least not unusable.

The bummer for me is how in max, visual layout actually influences order of calculations. If it didn’t, they could be separated and the “business logic would be diff able.

FWIW, similar problems afflict teams using things like Interface Builder in Xcode.

7 Likes

One of many reasons why we can’t use it in my day job.

Trying to think about why I use git w/max and never have problems… then it occurred to me all of my recent Max development makes very heavy use of externals. I use max just for routing and UI, and maybe a little maintaining of legacy objects, and of course their event API.

So I effectively just use C++ and avoid the visual programming which guarantees all the important stuff works nicely with git.

(general shout out - totally cool with all the max discourse happening in this thread)

agree w/ most if not all of the critisisms so far

redeeming factors for me:

  • only programming language that integrates with a daw (big one)
  • I like visual patching for programming
  • help files are some of the best out there, gotta say
  • great for prototyping
  • seems more approachable than pd for beginners
  • max coding is really relaxing for me?? idk??

really want to try pd soon, but sceptical of the observed complicated versioning situation, and lack of dev support (and, you know, ux. I do like the monochrome aesthetic though. and straight patch cables). also haven’t found a good learning resource/documentation.

I also want to try working more with gen/gen~/abstractions in max. doing non-audio with max objects is a big pain point for me, and also trying to get into low level audio zone (a-la gen~). I’m also very far from the dev chops that most of you probably have, I’m more of a music interface theorist with coding abilities.

3 Likes

I still use max every day. I should take on Lua and Supercollider, but procrastinate a lot because it’s frustrating to struggle with tasks that I’m already good at.

Ditto for pd. I seriously need to dive into that, and the only thing stopping me is that I don’t want to.

Anyway… I don’t really see the appeal of development megathreads, myself. I suppose the natural selection aspect of ideas getting lost as they aren’t latched onto makes for a leaner community, but I always liked the more “forum as wiki” approach of just treating each post like an ongoing article.

(I think the informal “one thread for every app” paradigm on the old forums kept a lot of apps alive that would otherwise have gone abandoned. Or at least, abandoned much faster.)

I say this mostly out of ignorance, however. As someone who’s never gotten up to speed with git, or gist, I’m sitting in the centralized discussion, unaware that those focused explorations of smaller ideas are even happening, somewhere.

(Assuming they are. I’ve pieced together that they probably are, and that this is where I’ve fallen short in my ability to join them, but that’s still sort of an abstract hypothesis. Y’know?)

Anyway, that’s on me. There’s just more of an onboarding process to development here than there used to be, is really my point.

*shrug"

2 Likes

I’m also using Max very often. As a matter of fact, I started today working on a sequencer idea for grid + arc.
I remember back in the days, 2006 or so, on the original monome.org forum, how everything was centered around Max/MSP. I keep wonderful memories of this time where I received so much help from great people.
And I still find that Max is a great platform to create grid/arc applications. It seems to me way easier to learn than SuperCollider for instance. People like me are still far from being experts with Max after more than 10 years of serious usage.
I love doing my own stuff (or heavily modify other people’s creations) and I feel like I can with Max. But in all honesty, Monome sort of lost me with Aleph (that I bought and sold) and Norns (that is in a drawer, waiting for some day when I have time…).
Well, I feel lost also because of language limitation, being French.
So yeah, I’d be happy to see more Max-M4L action here in lines !

10 Likes

Turns out…all that’s missing is the DSP part :slight_smile:

https://mermaidjs.github.io/

2 Likes

Oh neat. I’m happy to see that mermaid is getting maintained. Seems like it would be a great fit for the web audio API.

Edit: hmm, and/or this: https://www.webaudiomodules.org

One thing I love about web technology: sharing with the world is built-in.

1 Like

a lil update on this - tested stuff out, terms & gridlab seemed to play pretty well together.
@ithkaa’s elements seemed to keep disconnecting to the grid when I loaded it with other apps (could be something else though). confirmed that yea, terms doesn’t handle multiple instances, gridlab does though - I’m guessing that would be the place to source best code practices.

after mulling this thread over for a sec I feel like the best way forward here might be some kind of update/version of the terms package with devices that feel more relevant to what the community uses today (I’ve been working on an mlr and thinking up an earthsea - meadowphysics could port from the standalone afaik) - then a quick “max for live studies” for anyone looking to create compatible devices.

3 Likes

@andrew i wanted to bump this thread given the new existence of the Library category.

if there’s any energy to scrape recent/old forum posts and adapt them to the Library format, that may help spark some interest and attention to existing apps.

10 Likes

maybe not related to existing monome patches, but i think some of the content here is interesting,


and if “the piano is a vocoder for the hands”, the monome is like a vocoder onboard a bicycle for the mind…
1 Like