#28

happy to help with the study-making. I’m also not a Max wizard, but I am assimilating more of it as I chip away at my own projects.

2 Likes
#29

Happy to help try to break things and report back…

I have zero max chops but I am pretty good at breaking things…

I’m also a lawyer and college professor so I’m reasonably good at writing, proofreading, and editing… I could contribute on the side of helping documentation be more readable…

3 Likes
#30

I’m also happy to help in any way possible. I know Max pretty well!

[ddg]

12 Likes
#31

all of these are fine, but i would dissuade anyone from starting threads without first having content to contribute to them. just creating “containers” for content rarely produces actual content.

for example, i’m not sure how people will post to a “grid ideas” thread? do you have examples in mind of what you’d expect to see?

there’s already an entire Development category, so keep in mind that there might be (many) threads already overlapping into the Max Development territory. again imagine what a common post in Max Development would be?

m4l devices / max patches (i’ve never called a max-thing a “device” as m4l came after my time, i’ve always called them “patches?”) threads make sense as a wiki. threads to propagate links to other threads of individual max/m4l projects. again, don’t start these without first having content to populate. followup posts to this thread could just be requests to add things to the top post (wiki). so it can function as a directory.

3 Likes
#32

sounds good. I’ll certainly hold on starting any threads until the need arises (or someone else can start it, if they have the need), and I’ll make sure to articulate the intent specifically because I realize the titles I have can mean many things.

can anyone point me to a lines thread that’s a wiki as @tehn is describing? just so I have a better idea when I go to start these

#33

there really are very few. there’s one for the various monome eurorack module firmwares that @scanner_darkly made recently

#34

oooo but that looks so helpful ! exactly what we need for max rn

2 Likes
#35

I have quite some experience building professional max apps and M4L devices (spektroaudio.com). I admit I’m a bit lost in regards to the direction of this thread (looks like its a very meta thread about making threads) but I’m always interested in making stuff to help others.
Anyway, in my opinion I think the individual sharing threads in the C74 forum are quite cool and way better than single threads containing a bunch of different stuff because they allow for more “serialized” discussions around a more focused idea rather than multiple parallel conversions.

If anything I think a thread similar to the (Modern) C Programming Tips and Tricks but focused on Max but be extremely valuable for both beginners and more experienced users.

12 Likes
#36

Your stuff rocks!

Great to see you on lines!

#37

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
#38

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

Paging @darwingrosse…

3 Likes
#39

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
#40

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
#41

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
#42

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
#43

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
#44

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
#45

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

#46

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
#47

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