Sharing Everything Easily
Hi,
I know questions like this have been shared often but I am trying to clarify something. If I have a complex device (either a M4L device or just a Max Patch) and I want to share it with someone, or just use it on a brand new computer, what do I need to do to make sure everything needed (externals, .js files etc.) is included with the file. In looks like for a .amxd I can just freeze and save it, and that will include everything, I am curious for plain max though. I have downloaded many devices that come with a bunch of externals so I am curious.
Also. Let's say I have a big device that has bPatcher objects in it. If I want to change the objects in it, say change the .js code, but also keep the original page and original .js code, how could I do that?
Essentially, I want to change a .js file and make some slight changes to a patch, but also have the original (unadulterated) patch, which seems a bit hard because the bPatcher files may have the same name.
Thanks.
Packages.
Duplicating?
Thank you for the suggestion. When you say "duplicating" do you mean the entire package? Would that mean that I would alter the subpatchers (used by both).
Also, when you say packages do you mean build collective/application?
Use projects. it automatically keeps track of every dependency for patchers included in project, and you can one click consolidate your project, which copy pasts everything needed in a separate folder. It's awesome ! and probably exactly what you need ! so use projects !
??
if i understand you right you would have f.e. a patcher hello_world.maxpat in your bpatcher. you can have an older version of it for example as hello_world_08_11.maxpat. the bpatcher will still load a patch called hello_world.maxpat and not care about hello_world_08_11.maxpat...
@tobiasros : the philosophy of the newer "packages" feature is a bit different than that of "projects". "package" is for sharing LIBRARIES of EXTERNALS ideally, ie a collection of objects/abstraction you wrote yourself, and you want to share, and people with use one (or more) abstraction/object from that library in their patch, and with helpfiles for each object/abstraction you want. So you have to set up correctly your package in order to share.
Whereas the 'project' feature is there when you want to share a precise patcher, which is intended to be more played like an instrument, and the big difference is that 1) your projects folders are usually out of the default Max preference paths, allowing to install dependencies which are only used for one project, and 2) a patcher belonging to a projet will first look for what's inside the project folder, then for what is inside Max default paths.
Thank you both for your help and suggestions. Does this mean that, if the person tries to use the dependencies accompanying the project, in some other project, they will not work (or be available for use?)
My main questions is a little different than what these answers (though helpful) address. If you emailed me a M4L device, right now, that had a .js file that I did not have on my computer or an external that I did not, could I drag that directly into Live and use it? If so, where are those files (the .js file and externals) saved and could I use them in another project?
If I made changes to the .js file in max, would I be editing an outside .js file?
Does this mean that, if the person tries to use the dependencies accompanying the project, in some other project, they will not work (or be available for use?)
It means exactly the opposite : once you have the project folder, you have all the abstractions etc that accompany it. You can then either include this in your max path or copy this to an already existing max path.
If the abstractions are a set of abstractions designed to be included in the user's patching workflow, and if that means they should be installed in the user's extras/clipping/examples/init etc folders, you shoudl indeed rather use the package system for distributing.
In any of those cases, the user will have all the access he wants to the files contained in the things you distribute. If you want him not to access those fils, you have to build a collective/application (which, again, is easier from amax project) ; and for m4l instruments i'm not sure.
If you emailed me a M4L device, right now, that had a .js file that I did not have on my computer or an external that I did not, could I drag that directly into Live and use it? If so, where are those files (the .js file and externals) saved and could I use them in another project?
amxd files (m4l patchers) are by default located along with your other Live devices (on mac : ~/Library/Application Support/Ableton/Library/Presets/, then Instruments/max Insturments, Audio Effects/Max Audio Effects and MIDI effects/Max Midi Effects). If i send you a max device it's a amxd file, i need to send you also any max abstraction or js file used inside for you to be able to use that device. Then i'm not sure : either you need to place all the files in the ableton default devices, and you need to place the amxd plus all dependencies in teh same folder, either you can place the amxd anywhere as long as you have all dependencies in the same folder, or there are other options, related to Live preference paths. Idk if anyone can 'lock' a m4l device, so as long as you have all the files you can do whatever with it (in accordance with terms of use !).
If I made changes to the .js file in max, would I be editing an outside .js file?
AFAIK, you can't embed a .js file in a patcher, ie any change you do to a .js file used by a max object needs to be saved in the original .js file.
Thank you for all your help Vichung. While I have you here, and to make sure I fully understand this topic, which is surprisingly complicated:
I have all of the default M4L devices installed, some of which I know have dependencies or reference other patches. They appear to be isolated .amxd files on my computer. Only when I open (as if to edit) them, do I see their contents. A project file is created in my Documents/Max for Live Devices/ that contains subfolders for media, patchers, code, discarded and externals.
How is it that I am able to have these devices working properly without all of these media, code etc. visible on my computer?
Also, if I use projects as you suggested (which is I found out the default for M4L devices, thanks Tobias) do I simply include the main .amxd file in the larger project folder? If I emailed you the project, it would have all of those subfolders and then somewhere in the folder, my .amxd patch as well? Where would be the "correct" place for you to put that folder?
Lastly, if in the project there was an external (like osc-route) that you wanted to use again and again, with and without my patch, would you have to import it into the Max search path so that it would be found without having to include my sent folder in the search path?
re : amxd working without you seeing dependencies, to be honest i don't know... this might be some kind of m4l specific format, close to the 'max collective' format (which is looking like an application, except you need max or max runtime to run it, and you can't edit it iirc). Or just installers that contain everything needed, and which are unpacked on first use.
As for sharing, i'm not too sure...maybe there is a way to create something like the default m4l packages that you describe hwich don't need dependencies, or install, maybe that's the default behaviour, once again as i'm not using m4l that much i can't help you precisely, and perhaps (surely, i hope) this is explained somewhere in the documentation of m4l. Anyway the safest way to share something would be to include the .amxd plus all needed dependencies. The correct place where i would have to install it is, as previously : either Live's and/or m4l's search paths, or if this is enough, just keep everything in the same folder.
Lastly : yes, i would need to place the external in question in my default Max search paths. The interest of having dependencies of a project in a path separated form the rest of your max search path is that you can have a different version of a same external just for one project, which can be useful for backward compatibility. Usually, if you want to use an external often, you prefer to download it from the main site where it is developped/maintained, and in which library it is included. If you are the developper of that external and also of a project which uses that external, the most correct way to do this might be to distribute a package for the externals you developped in a library, in which you may include the project you made in a separate project folder, as a "demo" for example... maybe... the differences are tiny, and there is many ways to achieve the same result in the end, it would seem.
hah.. wall of text again, with a tl;dr that would look like "i don't know" :p