You zipped the Set, dragged it into the chat, and felt like a good collaborator. Two days later the reply lands: a screenshot full of grey clips, a stack of missing-media warnings, and the words “did you forget the samples?” Nothing was broken on your machine. It broke in transit, and it broke for reasons that are completely predictable once you know what an Ableton project actually is.
Here is the idea that makes sending an Ableton project to someone else stop failing: a handoff is three separate problems wearing one coat. The samples, the plugins, and the Live version itself. Samples can travel with the project. Plugins never can, for licensing reasons. And version differences have to be settled before you send anything, because the other end is exactly where they stop being fixable. Solve them as three problems and the handoff works. Treat them as one zip and you get the screenshot.
Why the project arrived broken
The .als file sitting in your project folder is not the music. It is a recipe. It says “put the kick from this path on track one, load this synth on track four, set the filter to here.” When your collaborator opens it, Live tries to follow the recipe on a machine where none of those paths exist and half of those plugins were never installed.
That is why a naked .als weighs a few megabytes and arrives useless. Every sample reference points at a folder on your drive. Every device reference points at a plugin on your system. The Set opens, technically. It just opens as an outline of a track instead of a track.
So the job is not “send the file.” The job is: make the sample references travel, deal honestly with the plugin references that cannot, and confirm the recipe is written in a version of Live the other person can read. In that order.
Problem one: the samples
Live solved this one for you years ago, and the solution is still the single most skipped step in collaboration: Collect All and Save, under the File menu.
When you run it, Live copies every external sample the Set references into the project folder itself, under Samples/Imported. Live asks which categories of files to collect; say yes to everything unless you are certain the other person owns the same factory packs. After it finishes, the project folder is self-contained: the .als, a Samples folder holding the actual audio, and an Ableton Project Info folder Live uses for housekeeping. That folder, as a whole, is the sendable unit. The .als alone never was.
Those categories are worth knowing by name, because when a handoff fails it is usually one of them that was set to no. Live sorts the files your Set references by where they currently live and offers each group its own yes or no. In Live 11 and 12 that is Files from Factory Packs, the audio that came with Live’s own installed content; Files from User Library, your own samples, racks and presets filed under your User Library; Files from other Projects, anything the Set borrowed out of a different project folder, usually a bounce you dragged in from last month’s track; and Files from elsewhere, which is the rest of your machine: Downloads, the Desktop, the sample drive, the pack folder you never filed properly.
For a handoff, all four are yes. The only one worth an argument is Factory Packs, and the argument is that the other person owns Live too, so why copy content they already have. Sometimes fair, but it depends on their edition and on which Packs they actually installed, and being wrong costs you a second send. The other three are never optional: your User Library does not exist on their machine, that borrowed bounce lives in a project folder you are not sending, and “elsewhere” is where almost every grey clip comes from.
Two habits make this reliable instead of hopeful. First, run Collect All and Save as the last thing you do before a handoff, not something you did “at some point,” because any sample you dragged in since then is not collected. Second, check for missing files before you send: Live’s file management tools will tell you if the Set still references media it cannot find, and it is much cheaper to hear that from Live than from your collaborator. If your project folders are a mess of half-collected Sets to begin with, sorting out how you organize Ableton projects makes every future handoff shorter.
Check the collect actually worked
Collect All and Save says nothing when it half worked. It finishes, the dialog closes, the folder looks packed, and the files it could not reach still point at your drive. Ruling that out takes twenty seconds, and it is the difference between a handoff that opens and the screenshot this article opened with.
With the Set open: File, Manage Files, Manage Set. Live scans and reports on this Set: how many files it uses, how many still sit outside the project, and a Missing Files count with a Locate button beside it. You want zero next to Missing Files, and zero next to the files used from elsewhere, because after a real collect nothing should live outside the folder you are about to zip. If either number is not zero, the same panel is where you fix it: Locate points Live at a folder to search, and the external categories collect from right there.
Two causes account for nearly all of it. The first is a drive that was not plugged in. Live cannot copy a file it cannot see, so every sample on the external drive in your bag stays a broken reference while the collect reports success. Plug it in, relink, run it again. The second is the reason people swear they ticked everything: samples in your own folder on a second drive count as files from elsewhere, not Library content, so if that one option sat at no, your personal sample collection stayed exactly where it was. On your machine every path still resolves, so nothing looks wrong until it lands where drive D is someone else’s.
Do this check last, after the collect and any other change to the Set, right before the zip. Anything you drag in afterwards is not in the check.
Check the Live version before you send anything
This is the problem nobody checks because it fails silently until the worst moment. A Set saved in a newer version of Live will not open in an older one. Save in Live 12, send to someone on Live 11, and they get an error message, not your track. There is no official “save as older version” escape hatch, so this is not something the receiving end can fix. It has to be settled on your side, before the send.
The fix costs one message: “What version and edition of Live are you on?” If they are behind you on the major version, you are the one who has to adapt, usually by sending stems instead of the project. Edition matters too: if you are on Suite and they are on Standard or Intro, devices exclusive to your edition will show up unavailable in their copy of the Set, even though it opens.
Asking the version question every time feels pedantic exactly once. It is the same discipline as version control for your music projects: the boring check you do before the event, so the event is boring too.
Problem two: the plugins never travel
Samples are files, so they can be copied. Plugins are licensed software, so they cannot. Not through Collect All and Save, not through a zip, not through any tool, from anyone, ever. Your Serum patch travels as a reference plus parameter state. Serum itself stays home, because your license is yours.
On the receiving end, a missing plugin means a greyed-out device and silence where your lead used to be. Live will politely tell them the device is missing. It will not tell them what it sounded like.
The plugin list does two things. It lets your collaborator tell you up front which ones they do not have, and it tells you exactly which tracks need the insurance policy in the next section.
Freeze and Flatten: the insurance policy
This is the most underrated move in the whole handoff, and it directly softens the plugin problem. In Live 11 and 12, right-click a track’s title bar and choose Freeze Track. Live renders the track’s output, plugins and all, to audio behind the scenes. A frozen track will still play back on a machine that does not have the plugins installed, because what plays is the render, not the device chain.
Go one step further with Flatten, on the same menu once a track is frozen, and the track becomes plain audio permanently. The synth, the chain, the automation baked into sound anyone can open.
The tradeoff is real, so make it deliberately. A flattened track is sound your collaborator can hear, edit, chop and process. What it is not, anymore, is a synth patch they can tweak. So split the Set by how finished each part is:
- Finished parts: freeze and flatten. The sound is decided; ship the sound.
- Parts still being written: leave them as MIDI plus device, and accept they are only editable by someone who owns the plugin. That is what the plugin list is for.
- Not sure: duplicate the track, flatten the copy, keep the original. They get the sound and the recipe.
One practical note: the audio Live renders for frozen tracks lives inside the project folder, so a Collect All and Save after freezing keeps everything together. Freeze first, collect second, send third. That order matters.
When stems beat the project file
Sometimes the right answer to “how do I send them my project” is: don’t. If your collaborator is on a different DAW, a project file is worthless to them no matter how carefully you pack it, and no archive format changes that. If they are a vocalist, a mix engineer, or anyone who does not need your arrangement view, stems are also simply the more considerate delivery.
Stems done properly follow a short spec, and following it is what separates “here are my stems” from “here is a folder of riddles”:
- Every file starts at the same point, from bar one of the arrangement, even if the part comes in later. Silence at the front is what keeps everything aligned on import.
- One file per part: kick, bass, lead, vocal. Not one file per plugin experiment.
- Same sample rate and bit depth across all files, matching the session.
- Names that make the order and content obvious:
03_Bass.wavbeatsAudio 14.wavevery day of the week. - Plus one reference bounce of the full rough mix, so they can hear what the stems are supposed to add up to.
Ten minutes of export discipline, and the other person starts working instead of reverse-engineering.
How to actually send something this size
Now the logistics. A collected Ableton project with its samples typically lands somewhere between a few hundred megabytes and a few gigabytes. That single fact rules out email, which gives up around 25 MB. Your realistic options are a file transfer service or a shared cloud drive folder.
Zip the project folder before you send it either way, but be clear about why: zipping a project full of WAV files barely shrinks it, because audio compresses poorly. The point of the zip is integrity, one file that keeps the folder structure intact, instead of a loose pile where the Samples folder gets left behind in the upload. If you already keep your music projects backed up to Google Drive, a shared folder there doubles as the handoff channel, and the project is backed up as a side effect.
Transfer links expire. Shared folders do not. For a one-off send, either works; for an ongoing collaboration, the shared folder saves you re-uploading the same track nine times.
When it lands: the recipient’s half
A good half of the failures on this route happen after the file arrives, on a machine that is doing everything right except the first step. So if you are the one receiving, this part is yours.
Extract the zip completely before you open anything. Windows will happily let you look inside a zip and double-click the .als from there, which hands Live a lone Set with no Samples folder beside it. It opens. It opens broken, and your first instinct is to message the sender about the samples they did not forget. Extract to a real folder on a real drive, next to your other projects, not into Downloads where it will get lost. If it came through a shared cloud folder, wait until every file shows as downloaded rather than as a placeholder, because a placeholder is not a file and Live counts it as missing. Then open the .als from inside the extracted project folder.
The warnings that follow mean two different things and it is worth telling them apart. Media files missing is samples: the Set is looking for audio at paths that describe the sender’s machine, and grey silent clips in the arrangement are the same message. A device greyed out with a name on it is the other class entirely, a plugin you do not own, and no amount of relinking will fix that one. Check it against the plugin list that should have come with the project.
Relinking is the same panel the sender used: File, Manage Files, Manage Set, then Locate beside Missing Files. Point Live at the extracted project folder itself and let it search. If the sender collected properly and you extracted properly, the audio is all in there and Live repairs the references in one pass. Then save the Set, because a relink you do not save is a relink you do again tomorrow.
What you send back matters more than “got it, thanks”. Send three things: that Manage Files now reports zero missing files, the list of devices that came up unavailable, and a bounce of the first thirty seconds. The bounce is the real confirmation, since it proves the project makes sound on your machine rather than merely opening. The device list gives the sender something to act on: they freeze and flatten those tracks, send you the audio, and nobody spends two days guessing.
Or: let the archive build itself
Everything above is the manual version, and it works. It is also seven steps you have to remember at the exact moment you are excited to share a track, which is the moment nobody remembers anything.
This is the handoff Vantom automates. Collab Archive bundles a project, its samples, and your project notes into one zip, together with a readme recording what the project needs. On the receiving machine, an archive like that shows a banner listing the plugins the project requires, so the “wait, what do I need to install?” conversation happens before the first playback instead of after it.
One thing the archive will never do: include the plugins themselves. Plugin binaries are never bundled, for licensing reasons, and that is not a limitation being apologised for. It is the only legal way any of this can work, which is exactly why the archive lists what is needed instead of pretending to ship it. And your collaborator does not need Vantom to open the archive. It is an ordinary zip, and everything inside opens anywhere.
Can you share Ableton with a friend?
Not the application, no. The question usually turns up in a specific shape: your friend does not have Live, you do, and it looks like the difference between the collaboration happening and not happening. The answer is still no, and it is worth being precise about why instead of vague.
A Live licence is issued to you and authorised through your Ableton account, so the authorisation follows the account rather than the machine. Which means “sharing Live” in practice means handing someone your account login. That is a licence breach rather than a clever move, and it is a bad trade for you specifically, because that account is where your licence, your Packs and every purchase you have made live. If the other person needs Live, the routes are theirs to take: Ableton runs a free trial, and Live Lite ships bundled with a long list of audio interfaces and controllers, so there is a decent chance the hardware already on their desk came with a licence they never registered.
What you can share is everything else in this article. The project, packed properly. Stems, when the project is the wrong unit. A Live Pack, when what you are handing over is sounds and racks rather than a track. All three travel legally and all three arrive intact, which is more than the alternative manages.
The checklist before you hit send
The whole article, compressed to the sixty seconds before the upload:
- Ask their Live version and edition. Newer Set, older Live: it will not open. Settle it now.
- Freeze and flatten the finished plugin-heavy parts. Duplicate first if you want to keep the editable original.
- Run Collect All and Save, after the freezing, not before.
- Let Live confirm there are no missing files left.
- Write the third-party plugin list and send it with the project.
- Zip the entire project folder, not just the
.als. - Send via a transfer service or shared drive folder. Email is not an option at this size.
- Different DAW on the other end? Skip the project entirely and send stems from bar one, plus a reference bounce.
Eight steps, or one button. Either way, the goal is the same: the project opens on the other end sounding like the track you made, and the first message back is about the music. That is the entire point of sending it.