Looking for documentation/tutorials on saving 'Projects'

    Feb 29 2012 | 6:32 am
    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.

    • Mar 01 2012 | 12:10 am
      Yeah yeah, but its pretty minimal…
      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
    • Mar 01 2012 | 3:03 am
      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.
      On to my questions!
      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.
    • Mar 01 2012 | 3:04 am
      Well, that was long. Hope I didn't get anything wrong!
    • Mar 03 2012 | 6:45 am
      Thanks MuShoo
      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.
    • Mar 03 2012 | 7:53 am
      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...
    • Apr 23 2012 | 7:17 pm
      So trying to set up my patch as a project and really feeling the 'no documentation' burn.
      A couple of questions.
      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?
    • Apr 23 2012 | 8:44 pm
      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.
    • Apr 23 2012 | 9:58 pm
      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.