Git/Github for revision control of max patches/projects?

Jul 30, 2013 at 12:06pm

Git/Github for revision control of max patches/projects?

Anyone using git or github for revision control?

Like basic one thread development. From what I’ve been told it does not handle branches/merging well at all, so nothing crazy/robust.

Or more specifically, anyone using it to handle Max Projects?

I’m wanting to get into git for max, but the lack of talk about it on the forum is a little worrisome.

#257619
Jul 30, 2013 at 5:29pm

well i’m planning to try soon-ish, but i’m not sure what it will give… the only sure thing is that Github is more awesome for text-based programmation languages. You can sort of understand some things reading a max patch as text, but….

#257643
Jul 30, 2013 at 5:32pm

Yeah, not ideal, particularly as the visual diffs, I would imagine, would be presented that way (as text).

If nothing else, it would be super convenient to make a big change to my code and know that I have a bunch of safety blankets to roll back to.

#257645
Jul 30, 2013 at 8:31pm

I’ve been using git for my Max stuff for some time now. Text diffs are pretty much impossible because a minor change to a patcher can change the order in which the objects are stored so it looks like everything has changed.
However, detailed comments when you commit stuff makes it reasonably easy to regress if you need. The branching system is also extremely handy as it lets you easily do some experiments (and keeping history) without risking your production code.

The free SourceTree app from Atlassian is (in my opinion) the best GUI client for git out there.

#257647
Jul 31, 2013 at 2:26am

Do you do branching with max/git? As in different branches which you later merge? Or do you mean just having an experimental branch that you don’t commit to the main code until you’re happy?

#257654
Jul 31, 2013 at 7:19am

I do branching but I wouldn’t even dare to try and merge stuff, it would be a disaster. But I will have several branches so that I can try experiments and once I’m happy with something in a branch, I will just copy the changed patchers (very carefully) back into the main tree

#257671
Jul 31, 2013 at 7:58am

what is in merge function that is not suitable here ? if you use github, but you can’t merge, it kinda loses some of its interests…

#257675
Jul 31, 2013 at 9:25am

You can merge, but you have to manage each ‘.maxpat’ as a binary. You can configure your repository with a ‘.gitattributes’ file to avoid messy things.

#257695
Jul 31, 2013 at 2:07pm

So you merge whole files, and not individual?

I’ve not set a git up yet, but I’ll have a look at .gitattributes.

#257724
Aug 1, 2013 at 1:44am

When i am using git with max i try to use many abstractions so it is easier to merge only specific edited parts of the patch. But this is also sometimes a pain in the ass.

#257752
Aug 1, 2013 at 4:07am

For me, the merge is much less relevant than having a history of changes. What I care about is the ability to create temporary branches so I can try some things out (and still leverage history to revert) without impacting production. Once I’m happy with a particular change and have tested it sufficiently, I just overwrite the original with the changed object.

#257763
Aug 7, 2013 at 1:15am

Ok, so I finally sat down and made a git and had a git-ty friend help me with some of the particulars. Worked pretty well I must say. Even managed some merge stuff without much incident.

Graned it was a small-ish project, and I did lots of mini edits just to test the revision/branch/merging stuff.

We did run into some peculiarities, so I figured I’d ask here to see if anyone has run into similar.

1) A couple revisions in I had a bunch of entries for ‘dependency cache’ (using “bootpath”) that used absolute links. This may be just a maxproject problem, but those will always get changed when the patch/project is shared. From my understanding, absolute paths are not ideal.

2) It kept doing this patcher name thing where it would change the length of a string looking like this:
“[1][1][2][3][1][etc]”
It would become one character longer/shorter in some edits seemingly for no reason.

3) An inlet switched ID from “signal” to “” with no changes to the patch.

Lastly, has anyone tried creating static/absolute “id” values to see if that prevents Max from willy-nilly changing the assigned ids around with git-ting?

#258221
Dec 9, 2013 at 8:46am

There is a solution for the automatic reordering of the patch file contents, described in http://cycling74.com/forums/topic/git-and-max/#post-134055. This should significantly reduce the number of changes you see when merging or simply comparing.

You can send a new message to Max like this (or put it in an init file):
;max sortpatcherdictonsave 1

This makes it so that the JSON files that are used by Max for saving patches will keep the dictionary in the same order (alphabetized) every time you save. If you are keeping your patches in version control then this should make your diffs a lot more usable.

#275209
Dec 9, 2013 at 11:03am

Hah, very useful information, thanks ! do you use that btw ?

#275219
Dec 9, 2013 at 2:53pm

Yes, I do have this setting enabled. However, you still have to compare the textual representation of the patches, which can be quite painful.

I’m wondering if the community would support the creation of a graphical Max patch comparison tool. I have done stuff like that before, albeit with other types of diagrams. Any love for the MaxDiff?

#275259
Dec 9, 2013 at 7:01pm

I’d love the pants off that…

#275271
Dec 10, 2013 at 3:06am

Great to hear that! I have found a more fitting topic for continuing this discussion: Diff for .maxpat

It would be great if more experienced Max programmers like yourself would chime in, and help me with figuring out the most common use cases.

#275301
Dec 10, 2013 at 3:08am

All of the Jamoma project is versioned using Git and GitHub:

https://github.com/jamoma/

#275302
Dec 10, 2013 at 5:21am

Common use cases would be difficult to figure given the different programming styles. I’ve been ok without diffs for now as I’m mainly using abstractions, but a couple years ago I had more of a ‘single big patch’ kind of thing, where diffs would be hard to visualize/manage anyways.

Hmmm.

#275312
Dec 10, 2013 at 5:58am

Of course the use of abstractions reduces the size of diffs, and it’s a good approach in general.

In terms of visualization, once an approximate rendering of the patch diagram is shown on the screen, it could be as simple as marking objects with different colors:

  • added = green
  • deleted = red
  • changed = yellow

Regarding the connections between objects, marking them as added or deleted is all we can do.

Initially, the tool would be read-only. If it catches on, then the merge functionality can be added as well.

#275313
Dec 10, 2013 at 6:02am

Ah right, yeah that would be great. And connections as text would be more than enough I think.

#275314
Dec 10, 2013 at 6:17am

What do you mean by “connections as text”?

#275316
Dec 10, 2013 at 7:00am

I meant your reference to connections between objects being rendered as text.

#275320
Dec 10, 2013 at 7:45am

Oh, I might not have been clear enough on that.

What I meant was that added connections would be drawn in green, and deleted connections in red. Since they have no unique ID, the only way to identify them is by the inlet and outlet they connect. Because of this, marking a connection as changed does not make sense.

I will create a couple of UI mockups to illustrate my ideas.

#275329
Dec 10, 2013 at 9:32am

Ah right. That’s even better!

#275342
Dec 10, 2013 at 10:25am

But… Are you confident you can create diagrams out of max patcher text files ??

#275346
Dec 11, 2013 at 1:21am

But… Are you confident you can create diagrams out of max patcher text files ??

The patchers are stored in JSON format, which makes them very easy to read and process. From what I’ve seen, all the required graphical information is in there, so it shouldn’t be a big deal. I’m not necessarily aiming for a 100% perfect replication of how it looks in Max, I just want to make it look close enough.

#275393
Dec 11, 2013 at 2:05am

For what it’s worth, generally when merging branches etc. in Jamoma, merges of patches work out well. If we get conflicts, the best way of resolving them is to open both original versions (local and remote), and visually inspect what the difference might be. It of course helps a lot to keep patches tidy and limit their size. Additionally, encapsulations also is really useful.

C74 has put a lot of effort into formatting the JSON files in a way that simplifies git versioning. This works well enough for us in the Jamoma project currently that I personally don’t feel the need for a solution that visually displays what objects and patch chords have been altered, added or deleted.

#275396
Dec 11, 2013 at 4:33am

My experience with Max patches and GIT was significantly more problematic than what Trond reports.

Basically, in the project where we were using GIT, we found GIT’s merging of different versions of a Max patch never worked at all. The result was invariably a file Max couldn’t parse due to multitudes of errors. We always had to do a manual update based on visual comparison of different versions, a process that was easily prone to error. In the end we tried, as much as possible, to only have any one developer at a time making changes to any one Max patch, and keep those changes always in the main branch. (And, yes, I do know about the sortpatcherdictonsave incantation. It helps a little. Sometimes.)

It was these difficulties with GIT and .maxpat that provided the primary incentive for starting the thread on a “diff for Max patches.” I’m absolutely sure this is an achievable goal (it’s more straightforward than resdiff, for those who’ve been around long enough to recall what that was), and I’m very excited that Sequadion is considering taking that on.

Also, sure, the .maxpat files contain all the information needed to make a visual rendition of a Max patch, even for someone without access to the Max code base. Maybe not a down-to-the-last-pixel exact replica of what Max does, but good enough to make comparisons. For example, rendering GUI objects would be sort of a PitA to get going, because the basic look is stored in a .SVG file located somewhere deepish under the /Applications/Max [version number]/ file hierarchy, and the final look may be tweaked by code known only to the external object (.mxo or .mxe file). But a labeled box with inlets and outlets would be more than sufficient for understanding where changes have been made to a patch.

#275404
Dec 11, 2013 at 9:37am

Would love to see this but while you’re at, a tool that would allow patches pasted into forums to be visualized would be wonderful. Consider how much more easy it would be to respond to questions about patchers if one didn’t have to actually run Max first (or accessing forums from computers without max installed, iPads, for example)

#275428
Dec 11, 2013 at 10:08am
#275434
Dec 11, 2013 at 12:08pm

hahaha Nicolas, this is really nice (though it says “no tablet support yet” :) ) how did you find this ?

#275454
Dec 11, 2013 at 10:35pm

The author published the link in the forum months (years?) ago.

#275478
Dec 12, 2013 at 7:47am

Nice. I never saw that before. Would be nice if this was integrated into the main forum system (and worked on an iPad -:)

#275518
Dec 12, 2013 at 8:46am

Nice. As I said, not pixel-for-pixel identical. What surprised me were the differences in back-to-front order.

But, hey! good enough for jazz.-)

It looks like most of the work is done with JavaScript, but the heavy-lifting is probably done server side. So it could be anything (Sequadion had been musing about what language to use in the other thread).

#275524
Dec 12, 2013 at 10:10am

Great to see this topic come back to life, I appreciate everyone’s input.

For example, rendering GUI objects would be sort of a PitA to get going, because the basic look is stored in a .SVG file located somewhere deepish under the /Applications/Max [version number]/ file hierarchy, and the final look may be tweaked by code known only to the external object (.mxo or .mxe file).

Well, if the custom graphical elements are SVG files, I could try and get permission from C74 to use them. This would probably get the tool quite close to the original rendering without having to write too much custom code. But I’m getting ahead of myself; the proof-of-concept implementation could simply draw boxes instead, like you suggested.

Would love to see this but while you’re at, a tool that would allow patches pasted into forums to be visualized would be wonderful.

http://www.ahmetkizilay.com/ptc/

It looks like most of the work is done with JavaScript, but the heavy-lifting is probably done server side. So it could be anything (Sequadion had been musing about what language to use in the other thread).

My intention is to split this into two, independently usable parts: the diff engine and the patch rendering.
The existing JavaScript renderer looks pretty good, I will get in touch with the author to see how much of that I can reuse. I’ve been playing with JavaScript for a while now, I guess it’s time to use it in a proper project.

This brings up the important question how people would want to use this tool: as a desktop application or as a web application? A web application is probably OK for open-source projects, but that might not be the case for proprietary stuff.
There is a way to support both types of deployments though: there are a couple of tools out there for packaging a Node.js backend and an HTML/CSS/JavaScript based UI into a standalone desktop application.

#275533
Dec 13, 2013 at 5:08pm

Just wanted to mention that I sent a pull request to the github linguist (https://github.com/github/linguist) to have better support for max patches. I changed the primary extension from mxt to maxpat, this means more of your projects should show up as Max and it should make searching for Max related stuff easier !
It seems to works as a lot of my projects that were tagged JavaScript or had no languages are now tagged Max !

#275690
Dec 13, 2013 at 10:59pm

Hi,

Thanks Nat. I opened several pull requests in the past without success (patch detected JavaScript swapped to blank but nothing better) before to give up. It seems that the githut linguist policy is more friendly now.

#275703

You must be logged in to reply to this topic.