Rodrigo

So after some weird funny business with my github repository I've figured out that .mxo files are getting messed up when being put up in github.

They seem to show up as folders, and if someone downloads the files from github, they don't run right, giving an error like this:

descriptors~: unable to load object bundle executable

2014-09-26 02:44:55.446 Max[3288:707] Cannot find executable for CFBundle 0x12fc80d0 (not loaded)

Here is my repo if you want to see what I mean (look at the first 4 items listed):

https://github.com/rconstanzo/the-party-van

Now, I can just find a way to distribute the patch without having the externals live in the same folder with it, but is there a workaround to this?

A couple of the externals I'm using are custom/specific and not part of a general external distribution I can point to, so it would be messy for someone to have to download the repository AND some externals, and then put them together themselves (defeating the convenience of using a github in the first place).

They seem to show up as folders, and if someone downloads the files from github, they don't run right, giving an error like this:
descriptors~: unable to load object bundle executable
2014-09-26 02:44:55.446 Max[3288:707] Cannot find executable for CFBundle 0x12fc80d0 (not loaded)

Here is my repo if you want to see what I mean (look at the first 4 items listed):
https://github.com/rconstanzo/the-party-van

A couple of the externals I'm using are custom/specific and not part of a general external distribution I can point to, so it would be messy for someone to have to download the repository AND some externals, and then put them together themselves (defeating the convenience of using a github in the first place).


github-corrupting-max-externals

I'm not in a position to look at your repo right now but .mxo "files" ARE in fact folders that contain files and other folders. The actual library lives further down, if I recall directly it's inside a MacOS folder that lives inside the Contents folder. So make sure you pushed all the files underneath.

Also, I have seen a case where, depending on the build configuration, where the actual library wasn't living where expected and only an alias to the library was in the location.

I'm not in a position to look at your repo right now but  .mxo "files" ARE in fact folders that contain files and other folders. The actual library lives further down, if I recall directly it's inside a MacOS folder that lives inside the Contents folder. So make sure you pushed all the files underneath.

Yeah, I had something like that happen before, where uploading an .app via dropbox would break symbolic links, but didn't know this would/could happen with github/externals too.

I didn't personally build the externals, and they've been working before, so they should just be self contained.

I didn’t personally build the externals, and they’ve been working before, so they should just be self contained.

To be honest, this is probably why you shouldn't include these in your github(most of github is for 'source' code that will change, and mainly the 'release' pages on github are for such fully-contained releases).

Best practice would be to put the externals in a fully self-contained 'release' .zip(.mxo will retain it's mac os 'package' file structure also this way). Savvy github users will then know how to use that as their starter repository, and when they pull the master 'source' each time you put out a new version, they will only be replacing the actual source .maxpat files that you worked on and changed.

So put that starter 'release' .zip(with all pre-compiled/required externals included) here on the 'releases' page, instead of a 'source' .zip like you did, it's what the 'releases' page is for anyways:

https://github.com/rconstanzo/the-party-van/releases

and then keep this repository as a 'source' only:

You won't be changing the externals much(since you didn't write them and are not providing the source code for those externs on your git at all), therefore they don't need to be part of the repository that would include 'source' code.

People can then start with the 'release'.zip. They can then get the actual files that will be changing from the github 'source' master thereafter(and there are github settings and commands which can make the versioning swaps more automatic on their comp... i'm just saying: savvy github users will know how to do this... in general, i think(especially after helping on your monome forum party van thread and seeing the resistance to keeping up-to-date there...example: 'tate', still havin probs, after we just told 'beo' to update, still reported being on max6.1.6 :p), most monomers are going to get confused with github and you just want an easy .zip on that releases page or just guide them to your monome.org-app page instead).

here's an example where they put both 'source' and 'release' on their 'release' page, you could do that too, on other githubs i've seen, generally there's at least a 'release'(ready-to-run) version posted there:

https://github.com/monome/llllllll/releases/tag/v1.1

Best practice would be to put the externals in a fully self-contained 'release' .zip(.mxo will retain it's mac os 'package' file structure also this way). Savvy github users will then know how to use that as their starter repository, and when they pull the master 'source' each time you put out a new version, they will only be replacing the actual source .maxpat files that you worked on and changed.
So put that starter 'release' .zip(with all pre-compiled/required externals included) here on the 'releases' page, instead of a 'source' .zip like you did, it's what the 'releases' page is for anyways:
https://github.com/rconstanzo/the-party-van/releases
and then keep this repository as a 'source' only:
https://github.com/rconstanzo/the-party-van

You won't be changing the externals much(since you didn't write them and are not providing the source code for those externs on your git at all), therefore they don't need to be part of the repository that would include 'source' code.
People can then start with the 'release'.zip. They can then get the actual files that will be changing from the github 'source' master thereafter(and there are github settings and commands which can make the versioning swaps more automatic on their comp... i'm just saying: savvy github users will know how to do this... in general, i think(especially after helping on your monome forum party van thread and seeing the resistance to keeping up-to-date there...example: 'tate', still havin probs, after we just told 'beo' to update, still reported being on max6.1.6 :p), most monomers are going to get confused with github and you just want an easy .zip on that releases page or just guide them to your monome.org-app page instead).

here's an example where they put both 'source' and 'release' on their 'release' page, you could do that too, on other githubs i've seen, generally there's at least a 'release'(ready-to-run) version posted there:
https://github.com/monome/llllllll/releases/tag/v1.1


Yeah that makes sense. I just like the convenience of having the github being a mirror of my 'live' folder, which includes local versions of app specific externals.

I will definitely do a zip/dmg with all the needed files for the next party van version update. I learned how to use github more since making the first (and only) TPV release, and have been trying to iron out bugs and stuff before doing another release.

For another repo I did do the dmg/source combo thing:

https://github.com/rconstanzo/dfscore-performer/releases

I will add the gitattributes thing as well to be safe, and for the next (v1.1) release make a nice tidy source/app distinction.

I've been wanting to go to a maxproject format too, but now with github, and doing a compiled app, I don't know if I want/need to do that anymore.

For another repo I did do the dmg/source combo thing:
https://github.com/rconstanzo/dfscore-performer/releases

I've been wanting to go to a maxproject format too, but now with github, and doing a compiled app, I don't know if I want/need to do that anymore.


GitHub does NOT corrupt externals properly pushed

yes, gitattributes = good(did not mean to post anything in contest of that...)

(i wonder-if/hope max7 might have some improvements for incorporating 'project's into 'git's or other versioning systems...)

So going to do some variation of that, but at the moment I can't figure out where the .gitattributes file is supposed to go. I tried putting it in the root level (as in NOT inside the .git) but that didn't seem to work.

I could be doing the procedure wrong, but I deleted the local externals, created/added the .gitattributes file in the root folder, placed fresh versions of the .mxo files in the root folder, and then pushed it back to github (using SourceTree).

The .mxo files work for me, but someone else downloading the repo has the same error listed in the original post.

Hmm weird. The MacOS folder (and the executable) is in my local version, it's just not getting pushed to the github.

I seem to recall that GIT had a method for excluding certain subdirectories from the push/pull protocol. It's been ages since I had to do this, but something you might want to look at.

I have to admit that I found GitHub less than ideal when editing Max patches, but that has more to do with the rather arbitrary way Max orders components of its JSON data structures on save. Has this gotten any better?

To exclude files or folders from the repo you can list them in the .gitignore file(s). take a look at the git reference for the wildcard syntax.

if a file/folder is already added to a repo before the .gitignore is created the will remain part of the repo unless you explicitly remove them.

To exclude files or folders from the repo you can list them in the .gitignore file(s).  take a look at the git reference for the wildcard syntax.
if a file/folder is already added to a repo before the .gitignore is created the will remain part of the repo unless you explicitly remove them.


Yeah I wanted to add a gitignore, but just structured stuff so that nothing lives in the git that doesn't need to be there.

Is there a reason why my MacOS folders wouldn't be getting pushed to github?

Oh I see. I thought that was a general comment on git structuring. I shall test pushing that.

Put that in an init file, and your diffs will get better.

I've wondered about using that message but never got around to testing it to make sure that it was 100% reliable. Seems to me that it would have made sense for a sorted safe to be the default unless the way patchers are normally saved leads to some load optimization.

So do you just loadbang that in a top level patcher every time?

Does it need to be in each individual abstraction?

So do you just loadbang that in a top level patcher every time?
Does it need to be in each individual abstraction?


What I've done is to make a file here: .../Max x/Cycling '74/init/sort-on-save.txt

I think that the default ordering of objects in the patch file is first-touched to last-touched. I suspect that is how they exist in memory, so sorting them on save would incur a slight penalty. I doubt there would be any effect on load optimization. Personally, I think this should be the default setting, or settable by a preference. But, I guess the number of people who use version control on Max patches is pretty small.

What I've done is to make a file here: .../Max x/Cycling '74/init/sort-on-save.txt 

I think that the default ordering of objects in the patch file is first-touched to last-touched.  I suspect that is how they exist in memory, so sorting them on save would incur a slight penalty.  I doubt there would be any effect on load optimization. Personally, I think this should be the default setting, or settable by a preference.  But, I guess the number of people who use version control on Max patches is pretty small.


@Mzed: Yes, I know the message and have used it.

No, it's not really proven to be a big help. Not in two-people-editing-at-the-same-time situations (which, otoh, GIT handles reasonably well with procedural code).

@Mzed: Yes, I know the message and have used it. 

No, it's not really proven to be a big help. Not in two-people-editing-at-the-same-time situations (which, otoh, GIT handles reasonably well with procedural code).


Does anyone know of any improvements to GitHub/Max Project technique since 2014, or for the upcoming Max 8? Thanks

Github corrupting max externals?