George Khut

hello, can anyone point me to documentation on how the new save as 'Project' method works? I've been searching through online documentation and forums, but cant seem to find much re how Projects work, how you can edit them, create them and repair them (i.e. "unable to locate…"

This looks like a hugely significant new feature - one that I've been waiting for for a while now - working as I do with lots of abstractions and 3rd party objects/abstractions.

looking-for-documentationtutorials-on-saving-projects

https://cycling74.com/docs/max6/dynamic/c74_docs.html#projects

https://cycling74.com/docs/max6/dynamic/c74_docs.html#project_window

Would be helpful to have some guide as to how to use and interpret stuff like

"include in project" (I assumed it was already if it was in the Project window)

"Use Global version" - whats a global version?

Am I asking too much here - the documentation for building collectives and standalones is very comprehensive - I look forward to more in-depth documentation for this brilliant new way of sharing max projects

Would be helpful to have some guide as to how to use and interpret stuff like
"include in project" (I assumed it was already if it was in the Project window)
"Use Global version" - whats a global version?
"Overwrite Project Local Version" ???
"Update Dependencies" etc.

Am I asking too much here - the documentation for building collectives and standalones is very comprehensive - I look forward to more in-depth documentation for this brilliant new way of sharing max projects


I've been using projects quite a bit, I can answer some of those, and then add some of my own as well!

"Use Global Version"/"Include in Project" - if you have an abstraction or external that you are referencing in one of your project-patchers, you can choose to either store a copy of that abstraction or external with the project - which gets priority over the 'global' version that is kept in the Cycling '74 folder. When you say 'use global version' you're saying ignore (possibly delete, does a c74 person want to chime in on that?) the project-local version, and reference the one in the c74 folder.

Overwrite Project Local version is related to that, though I haven't seen it pop up for myself it seems like it would mean 'replace the project local version of the selected item with the global one.'

Update Dependencies likely runs a check through any stored patchers, see if there's any new externals or abstractions that have been referenced.

All of this folds into the major benefit of the Projects workflow - building apps/collectives. By having all of these abstraction/externals/media/code/etc references, you no longer have to write the build scripts that you did in Max 5 - that is all handled for you. Well, mostly.

Why doesn't the project workflow, when building a standalone app, copy over the relevant java/jitter frameworks all the time? I still have to manually move the max.jar files and one of the jitter frameworks (I forget exactly which) manually.

The 'patcher opens on project open' function is nice but I'd love to have it split a bit more - define a patcher as the 'main' patcher for building standalones, but don't require me to have it open whenever I open the project file.

Conversely, it seems that Max can (not always) crash when trying to build a project into a standalone while there is no 'Open on Project Load' patcher defined - if there isn't a crash, there's no feedback in the Max window or anywhere else that notifies me why my app didn't build.

Also, every now and then my projects will get confused - they're referencing the global version of an external, which hasn't moved a micron (electron?), but suddenly it's 'missing.' Until I re-instantiate it from within a patch in that project. Very odd.

All of this folds into the major benefit of the Projects workflow - building apps/collectives.  By having all of these abstraction/externals/media/code/etc references, you no longer have to write the build scripts that you did in Max 5 - that is all handled for you.  Well, mostly.

Why doesn't the project workflow, when building a standalone app, copy over the relevant java/jitter frameworks all the time?  I still have to manually move the max.jar files and one of the jitter frameworks (I forget exactly which) manually.

Also, every now and then my projects will get confused - they're referencing the global version of an external, which hasn't moved a micron (electron?), but suddenly it's 'missing.' Until I re-instantiate it from within a patch in that project.  Very odd.


Well, that was long. Hope I didn't get anything wrong!

Well, that was long.  Hope I didn't get anything wrong!


quite a lot to think about re managing versions of objects, especially when you are working on multiple Max projects at once - mmm thanks for helping me understand the 'global/local' stuff.

quite a lot to think about re managing versions of objects, especially when you are working on multiple Max projects at once - mmm thanks for helping me understand the 'global/local' stuff.
Cheers
G


Honestly I really enjoy the new Project structure - it makes my life SO much easier. My only real issue is that I can't get it to recognize other patchers in the Project as 'abstractions' for some reason - I put them in the c74 folder, works fine, but can't keep them in the local project.

Works for poly~ and pfft~ objects though, and that's handy in and of itself. And it'll store your media files for you, and all sorts of other niceties. It feels very related to Presentation Mode to me, in that it just keeps getting that much easier to build rich, full programs in Max.

Now let me build plugins again! :P Or maybe a... like a max conduit plugin? Like re-wire but bidirectional and doesn't require an installation of soundflower by the end user. And allows for host-based automation to be sent to a Max standalone also running on the machine.

...Maybe i'll just try and write it myself...

Now let me build plugins again! :P Or maybe a... like a max conduit plugin?  Like re-wire but bidirectional and doesn't require an installation of soundflower by the end user. And allows for host-based automation to be sent to a Max standalone also running on the machine.

...Maybe i'll just try and write it myself...


So trying to set up my patch as a project and really feeling the 'no documentation' burn.

1) It seems like it doesn't like having externals (.mxo). All of them showed up as 'unable to locate'. I manually copied them into the project folder, but I'm not sure if that will work for other people (not to mention I'm sure that some externals have licenses that prevent that kind of willy-nilly distribution).

2) The help file says you no longer need to save, but doesn't clarify what this means. Is this like the OSX Lion autosaving type thing? As part of my workflow I often fork off a new version when testing new bits or heavily modifying old bits, just in case I break something. I would hate to be married to the same file.

3) Is a 'project' a good way to distribute a patch, as a patch. As in, I've been sharing all of my patches as editable code, rather than standalone stuff. I want to continue doing that, and was only looking to Projects in order to clean up my file structure. Is a 'project' for me, if that's what I want to do?

So trying to set up my patch as a project and really feeling the 'no documentation' burn. 

3) Is a 'project' a good way to distribute a patch, as a patch. As in, I've been sharing all of my patches as editable code, rather than standalone stuff. I want to continue doing that, and was only looking to Projects in order to clean up my file structure. Is a 'project' for me, if that's what I want to do?


1) I've noticed the issue with externals - I'm not sure what causes it. Sometimes it works fine, sometimes not so much. Seems like the best way to do it is to keep your externals in the main Cycling74 folder, and when you call them in a patch it'll add it to the project (in italics and with the word 'implicit') - you can then right click it and choose 'include in project' and it'll do the copy for you, and put it in the right spot.

2) The help file is confusing in this regard - you still need to save any PATCHES that are included in the project, but the project file itself (which is just an XML doc) saves whenever you add anything new to the project.

3) Yes, with caveats - you have to make sure that everything is still 'self contained' wrt the project. IE, make sure nothing is in italics, and it should work. Projects also make building standalones/MXFs a bit easier, as there's no need to write a build script. If you want to share the project, just make a .zip of the project folder.

Also, something I've noticed that's highly frustrating - if you make a copy of a project folder, the copy still references all the ORIGINAL files in the ORIGINAL project folder.

EG if I have 'Project A' and 'Project A Copy', and I open the 'Project A.maxproj' file within the 'Project A Copy' folder, the patches that open are the ones from the original Project A folder, not the expected 'Project A Copy' folder. This makes making backups or versioning a HUGE pain in the ass.

1) I've noticed the issue with externals - I'm not sure what causes it.  Sometimes it works fine, sometimes not so much. Seems like the best way to do it is to keep your externals in the main Cycling74 folder, and when you call them in a patch it'll add it to the project (in italics and with the word 'implicit') - you can then right click it and choose 'include in project' and it'll do the copy for you, and put it in the right spot.

2) The help file is confusing in this regard - you still need to save any PATCHES that are included in the project, but the project file itself (which is just an XML doc) saves whenever you add anything new to the project. 

3) Yes, with caveats - you have to make sure that everything is still 'self contained' wrt the project.  IE, make sure nothing is in italics, and it should work.  Projects also make building standalones/MXFs a bit easier, as there's no need to write a build script. If you want to share the project, just make a .zip of the project folder.

EG if I have 'Project A' and 'Project A Copy', and I open the 'Project A.maxproj' file within the 'Project A Copy' folder, the patches that open are the ones from the original Project A folder, not the expected 'Project A Copy' folder. This makes making backups or versioning a HUGE pain in the ass.


Yeah that all seems to point to 'pain in the ass', in terms of sharing and compatibility. I'd want to make it as easy to use/setup as possible, while still being editable (hence not wrapping it up as an application).

I've only just learned about path->thispatcher->filepath, so I'll probably just do that, and make a single folder for all the dependencies. Not super pretty as it apparently edits the file preferences globally/permanently.

Yeah that all seems to point to 'pain in the ass', in terms of sharing and compatibility. I'd want to make it as easy to use/setup as possible, while still being editable (hence not wrapping it up as an application). 

I've only just learned about path->thispatcher->filepath, so I'll probably just do that, and make a single folder for all the dependencies. Not super pretty as it apparently edits the file preferences globally/permanently.


I'm beginning to look at similar stuff now, trying to make that leap from beginner to intermediate (or intermediate to advanced?)

This is an old thread, but I still feel the lack of not so much documentation, but practical guidance. I've done a bunch of tutorials meaning I can make and use all sorts of great instruments, but have seen very little on how to manage these as larger projects, version control etc.

TL;DR - Can I make things globally accessible if needed, but saved locally only when they are used?

I write abstractions which I often use in bpatchers, then collections of these are used in a larger patch and controlled with pattr, MIDI etc.

If I'm trying to develop a piece, for simplicity lets say a synth with an oscillator, envelope, and filter, then right now I have a folder with copies of my osc.maxpat, env.maxpat, filter.maxpat plus their respective preset files. I also have a kind of home-made help file for each of my externals with a copy of that external already loaded into a bpatcher, as well a a handful of useful objects already plugged into the inlets and outlets - so I'll often just grab all that and paste it into a new patch if I want to use it.

If I want to load up two envelopes, one for the volume and one for the filter I give the bpatchers different arguments env01, env02, which means I only need one copy of the env.maxpat, but then I have two preset files env01.json and env02.json

This all works for me - I hope people and nodding while reading.

The problem is, say I want to develop two different pieces, so they'll have different preset files. I don't want these being saved in the same folder because they'll all start messing with each other. So I create new folders:

Folder Project01 contains project01.maxpat, osc.maxpat, env.maxpat, filter.maxpat, osc.json, env01.json, env02.json, filter.json

Folder Project02 contains project02.maxpat, sampler.maxpat, env.maxpat, filter.maxpat, sampler.json, env01.json, env02.json, filter.json, sample01.wav

So some shared files, but some different.

Along this line I've thought before it'd be nice if global versions of the externals all lived somewhere and I could just reference them like regular max objects, but what if later on I figure out there's a much better way of implementing my filter, but if I change it it'll break the way it used to work?

Well then I would want a copy of filter.maxpat as it currently works saved in the folder with all the presets etc. And this projects idea sounds like it might do that for me.

I'd love a global project that's got access to all my modules so when I'm building a new piece I can just load up an oscillator, give it a name creating a unique preset file for it, and save it as part of the project, knowing that if I change the global osc.maxpat later it won't go and break all my working pieces.

Right now I'm manually creating duplicates of the global project folder on my computer each time I want to write a new piece, but this might include a few handfuls of externals that aren't used in that patch. But if I copy just the stuff I want to use but later decide: oh I want a reverb with this too, I have to go dig up my reverb.maxpat, copy it into the new projects, but then also remember the reverb has a couple of dependencies like allpass.maxpat that I forgot to copy, and so on.

Folder Project01 contains project01.maxpat, osc.maxpat, env.maxpat, filter.maxpat, osc.json, env01.json, env02.json, filter.json
Folder Project02 contains project02.maxpat, sampler.maxpat, env.maxpat, filter.maxpat, sampler.json, env01.json, env02.json, filter.json, sample01.wav

Well then I would want a copy of filter.maxpat as it currently works saved in the folder with all the presets etc. And this projects idea sounds like it might do that for me. 

i strictly distinguish between general abstractions and project-specific abstractions, the latter gets name-tagged for the project to make sure they have a unique name.

while beeing "creative" i work a lot on the desktop, which is in my search path, use funny names for stuff, relative paths, or photoshop documents with multiple layers.

later i rename everything, assemble proper files and a proper project folder such as

max/110/applications/thisproject/pictures

max/110/applications/thisproject/bpatchers

in max 6 or higher you would eventually like to put projects into a /package folder, because then you can have a folder inside your project which is outside the search path. perfect to litter it with "old versions", "tutorials" and "does not work" kind of stuff.


i strictly distinguish between general abstractions and project-specific abstractions,  the latter gets name-tagged for the project to make sure  they have a unique name.

while beeing "creative" i work a lot on the desktop, which is in my search path, use funny names for stuff, relative paths, or photoshop documents with multiple layers.

later i rename everything, assemble proper files and a proper project folder such as

max/110/applications/thisproject/main
 max/110/applications/thisproject/pictures
 max/110/applications/thisproject/bpatchers

in max 6 or higher you would eventually like to put projects into a /package folder, because then you can have a folder inside your project which is outside the search path. perfect to litter it with "old versions", "tutorials" and "does not work" kind of stuff.


Looking for documentation/tutorials on saving 'Projects'