#25

Intriguing! I’d love to learn more about this as and when you’re able to describe in more detail, in the thread of your choice of course (with apologies to @andrew about any off-topic-ness in this thread).

2 Likes
#26

Regarding Max4Live, I would love to see a ‘best practices’ patch. In hindsight I wish I’d had that mentality when building the Terms package, but at the time I was disenchanted with the M4L workflow and just trying to get it to work. I believe I borrowed a lot from elquinto & stretta’s patches (along with others) when it came to track following etc, but I’m not sure I ever successfully got multiple instances of the same patch co-existing correctly.

As with all discussions of standards, the best way to adopt a solution is to offer a candidate that we can talk about concretely. @andrew if you’d like to select an existing patch, or take one and modify to collect the best of all worlds, that’d be great. The simpler the patch can be while encapsulating the design proposition the better. I wrote a Max patch yesterday for the first time in years, which is to say I’m probably not the candidate to offer a potential standard, but very happy to critique.

Edit: Let’s start a separate “Max4Live Best Practices” thread with a candidate so we can collect that discussion in one place.

8 Likes
#27

I went away for a sec and this thread became quite a few things lol. on the topic of supporting future max development:

this is a super 100% on-point way to address this problem that I hadn’t thought of before. I’d love to take it on in the near future if I can put some time aside for it. it’d be some work but I think it’s pretty needed and overdue. since I’m not a max genius it’d be helpful if some folks want to volunteer to check my work as I go along with it.

will do soon !

I think the best thing is just to take what we have, see what works and what doesn’t, update the old stuff and maintain a list of some working, compatible m4l stuff on the monome docs.

in terms of theads (thanks for addressing this @tehn):

would you mind clarifying this? the discourse-y talk tends to go over my head

sounds like I was misusing this term. I was just trying to bring up the possibility of one thread for all kinds of development on lines. could be interesting, could be problematic!

what I’m thinking for new threads right now:

max: development - I definitely want to start this one, I think we’re all in agreement on that part

grid: ideas - not totally sure if people will use this, but I like the idea

m4l devices - this would be good to have for finished new devices. like bigger grid apps and also little non-grid tools and stuff (I make these all the time, i’d be nice to just drop them somewhere in an unpolished state in case they’re of use). as we’ve said there’s also a need for consolidating old devices, but some docs updates would accomplish that as well. something I was considering was merging all the individual max device threads into this one so they’re easier to find, but idk :woman_shrugging:.

max devices: for new max standalones. I could also see just one thread for this and m4l devices.

another thing I brought up in the thread topic (vaguely) for the possible future of lines/max was the possibility of Beap-compatible CV-talking bpatchers as a platform for sharing grid/audio ideas on laptops (or, hey, maybe you can convince me to go pd and align with automatonism :wink: ). kinda solves the problem of standalone devices not working with others and m4l devices enduring the limitations of Abletion. @dan_derks and I have talked about this in detail - I’ve explored it some and I feel like there’s hefty potential as a sharing thing. food for thought / something else to investigate.

3 Likes
#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