Where to best put your M4L files / dependencies?

    May 20 2013 | 8:24 pm
    I find this subject rather fuzzy for M4L and I can't seem to find any clear documentation on it.
    When you develop a M4L patch with abstractions where do you put your files? On OSX I normally create a project in the default generated "Documents/Max6 Projects" folder.
    I know that you can put everything in one folder or all over the place and eventually freeze it. But when you edit/unfreeze a device, since Live9, it seems to generate a folder in "Documents/Max for Live Devices" with all the project files in a subfolder names "Yourdevice Project".
    Or...after unfreezing it generates a folder (not file) "Yourdevice.amxd" in that same location :S What is what, and whatfor? Unfreezing also gives me a dialog to open something, but I have no clue what it wants and just click cancel.
    Is it sensible to put your development files there also? Will they collide with unfrozen devices later? Is it only for temporary storage? And how does an amxd file relate to a maxproj file? Max seem to unpack an amxd file as if it were a project but you can't pack a maxproj into an amxd file?
    Lots of questions. I hope someone has a clear answer or pointer so some docs, cause at the moment I feel like I'm freewheeling myself towards some future conflicts.

    • Aug 26 2013 | 2:59 pm
      I have been dealing with some "freezing" issues myself. The best (and only) documentation I found was this: https://cycling74.com/docs/max5/vignettes/core/live_dependencies.html https://cycling74.com/docs/max5/vignettes/core/live_freezing.html http://downloads.ableton.com/misc/maxforlive_production_guidelines.pdf I guess a freezed device is like a zip file, a container for distribution. So when we unfreeze a new folder is created with the contents. One of the main difficulties is dealing with the assets of the device, databases, pictures, subfolders... etc in way that max can find them after freezing.
    • Mar 14 2015 | 11:53 pm
      I am currently struggling with this as well. I am amazed that I cannot find decent documentation for how to deal with my M4L object and dependencies, and right now it's a confusing mess split between the bowels of my "Ableton" folder and the "Max 7" folder.
    • Mar 16 2015 | 9:49 am
      Every Max for Live device is actually a Project. When the M4L device is opened/saved, a folder (named as the device) is created in ~/Documents/Max 7/Max for Live Devices, and the dependencies of unfrozen devices are unpacked into that folder. When you freeze the device, project dependencies are then automatically bundled into the .amxd file.
      Maybe you can provide some concrete devices/situations where this system is failing for you, so that we can suggest an appropriate workflow. And improve the documentation where necessary. I agree that this should not require much additional effort on the part of the device developer.
    • Mar 17 2015 | 10:21 am
      I think this problem arises if you are not using Max projects and have your sources elsewhere (at least it does for me)
      So, eg., if have all my source in myfolders/lee and this is separately pathed in
      i freeze a device into lee.amxd - all is fine. i unfreeze that device and it creates a new directory under mydocuments and unpacks the code - now I have 2 copies of it and things can get confusing as to which files you are editing (the ones under mydocuments or the ones under myfolders/lee)
      simple solution to this is to remove the created directory under mydocuments whenever you unfreeze your device and then you are always using the code from myfolders/lee.
      i'm currently starting to use max projects more and I guess this will resolve this situation as the source and unfreeze directory should theoretically be the same at that point...
      anyway, not sure if that is your situation, but if it is, there you go :)
    • Feb 01 2016 | 10:19 pm
      Lee, Even if you delete the files in the Max for Live Devices folder, they will be re-created, and it seems the frozen device will always use its internal files even if you edit the ones in the Max for Live Devices folder. The only way to edit abstractions and such then becomes by opening them from the device itself. That's my understanding anyway; I'm slowly becoming less confused, but I can't say I understand it completely.
    • Feb 01 2016 | 10:30 pm
      It may be that if you have your device open and unfrozen, you can edit the files in the Max for Live Devices folder and it will find them when you refreeze it. Just a hypothesis that I haven't tested. I'm having trouble understanding what the point of the Max for Live Devices folder even is.
    • Feb 02 2016 | 10:16 am
      @TO_THE_SUN Maybe it helps if you think about think about frozen M4L devices similar as a complied program. It is the state where everything that is needed by the device is inside one file, to make sure it runs without outside dependencies in any Live set on every computer.
      Like with compiled code: When you use an external library (in Max that would be an external or abstraction) a compiled program will always use the version it was compiled with.
      But compiled programs are not editable. That's why when you unfreeze a M4L device an 'un-complied' version of the code/patch is created in the MaxForLive Devices folder.
      To my understanding freezing is the last step in development. - basically when development is done. During dev i always work with unfrozen devices and use the global versions of external and non project-specific abstractions.
      To avoid confusions between abstractions that I use globally in different projects and devices and those that are project specific I "namespace" project abstractions by prefixing them.
      In general I think it is a good practice to keep all you M4L stuff inside the MaxForLive Devices folder and don't build them from outside locations.
    • Feb 02 2016 | 6:51 pm
      Right, normally I would never freeze a device until it's ready for distribution. Recently I started using the amxd~ object however which forces you to freeze your device continually and therefore seems to be more trouble than it's worth for anything that's not in a completely finished state.
      However, if you try to edit an abstraction saved in the Max for Live Devices folder, it will just be overwritten next time you unfreeze the device. What about if the device is already unfrozen and open? Then are the files in the folder the ones it will reference when it freezes again? If so, maybe you could edit them, but if the device is already open and everything you might as well just get to the abstraction in question by opening it through the device itself.
      Anyway, I never had issues with this folder until I started using the amxd~ object. For one thing, why would freezing a device create text files there of the contents of coll objects (not set to Save Data with Patcher)?
    • Feb 03 2016 | 5:32 pm
      yes, the overwriting without prompting when unfreezing is a real bummer. I wrote a feature request / suggestion a few month ago to cycling74. I think there should be either a modal dialog or overwritten files should be moved to the _DeletedItems folder inside the M4L project, so we could at least recover them.
    • Jul 19 2019 | 3:36 am
      Max 8 / Live 9 - my personal process for getting around this ridiculous issue
      1. work on your device out of whatever directory
      2. add the folder "<device name> Project" to "Documents/Max 8/Max for Live Devices" (if it doesn't exist already - for me usually it does not)
      3. add a subfolder depending on the type of file. this will either be: /code (.js or other?), /externals , /media (images), /patchers (abstractions)
      4. freeze. I think at this point the .amxd will take on the project folder as it's own. you can check by deleting the folder, freezing and unfreezing. it seems to just work.
      this feels performing surgery. absolute insanity. totally not the kind of issue I would expect from proprietary software and a company with full-time employees, but, whatever. it works now. just a huge bummer cause it prevented me from sharing my code for a while.
    • Sep 03 2020 | 8:44 am
      Here is how we deal with freezing at Showsync. For every new version of Videosync and Beam we have to distribute potentially updated versions of our Max for Live devices, obviously in a frozen state.
      On our development machines though (in git repositories, in our case) we have only a single, non-frozen, version of any .amxd and only a single version of any dependency. We prefer not to have these source folders in a default Max search path but rather to selectively add the folders containing dependencies to the search path using Options / File Preferences.
      If there is ever a reason to unfreeze a distributed version of a plugin, perhaps for debugging, afterwards we quickly remove the folder with copies of dependencies that is created in Documents/Max/Max for Live Devices.
      These are the reasons that we try to avoid unfreezing devices as much as possible:
      • Having copies of dependencies creates a risk of unintentionally editing the copies instead of the originals, losing work if the copies are subsequently deleted.
      • Multiple devices, unfrozen or never frozen, may have different dependencies with the same names. One device can use a filterlow.maxpat abstraction which is a lowpass dsp filter and another device can use a filterlow.maxpat which passes only values above a threshold. If both abstractions are in the Max search path, it is unclear for any of the two devices which version of the dependency will be used at which point. Both devices may well end up loading a different dependency than the one they started out with. Having untracked copies of dependencies in the Max search path increases this risk.
      • After saving a Live set with a newly unfrozen device, the Live set now depends on files in the Documents folder without the user getting notified about it. After doing Collect all and Save (which I generally also avoid btw), when moving the Live set to another machine, the device will be broken. Depending on the context, the dependencies may be gone and it may not be possible to recover the device.
      Finally, though this may go beyond the scope of most, for some time now, frozen versions of our devices actually never have to exist on our development machines at all since our devices are frozen automatically by our hosted continuous integration system, using a script we developed specifically for this purpose.
      Hope that helps!