Look at your Desktop. There is a Live Set on it. Somewhere further in there is a folder called new stuff 2, and at least three files named Untitled.als. Most advice on how to organize Ableton projects looks at that and prescribes a folder tree, usually something with genres and subgenres and a diagram, as if the problem were that you never got around to inventing a taxonomy. This article starts from a different place: Live already has a filing system. It builds part of it every single time you save, and nearly all of the chaos on your drive comes from fighting that system instead of using it.
So the plan is not to impose order on Live. The plan is to get out of Live’s way, add the two decisions Live cannot make for you, and then stop thinking about it.
Why your Ableton folder looks like that
You did not choose the mess. It accumulated one perfectly reasonable decision at a time. A quick idea caught between two other things, saved wherever the dialog happened to open. A Set dragged out of its folder to “tidy up”. A Project folder copied to a USB stick for a collab, then copied back next to the original, so now there are two and one of them is lying to you.
Every one of those moves shares a single misunderstanding: it treats the .als file as the project. It is not. In Live, the project is a folder, and the .als is one file inside it, surrounded by everything it depends on. Almost every organizational disaster in Live, the missing samples, the duplicate versions, the Set that opens fine on your machine and falls apart on anyone else’s, traces back to separating that one file from its folder.
Which means the fix starts with knowing exactly what that folder is.
How Live actually saves a project
The first time you save a new Set, Live does not just write an .als file where you point it. It creates a folder named after your Set with Project on the end, something like NIGHTS Project, and puts the Set inside it. Over the life of that project, Live fills the folder in:
| Inside the Project folder | What it holds |
|---|---|
NIGHTS.als | The Set itself: arrangement, devices, mixer state, and references to your audio. Not the audio. |
Samples/Imported | External samples copied into the project, mostly by Collect All and Save. |
Samples/Recorded | Audio you recorded into this project. |
Samples/Processed | Files Live generates on its own, like frozen and consolidated clips. |
Ableton Project Info | Live’s internal metadata for the project. Ignore it, keep it. |
Backup | Timestamped copies of your recent saves, in recent versions of Live. |
The line that matters most in that table is the first one. A Live Set does not contain your audio; it contains pointers to audio. Some of those pointers aim at the Samples folder sitting right next to the Set. Others aim outward, at a sample pack folder, at Downloads, at that one external drive. The whole craft of keeping Ableton projects organized is keeping the pointers and the audio together, and Live’s Project folder is the container built for exactly that job.
One more thing the Project folder does quietly: it can hold more than one Set. Save As into NIGHTS Project and the new version joins the family, sharing the same Samples folder instead of duplicating it. Remember that. It is the backbone of the versioning scheme in a minute.
The nested project folder trap
Live builds a new Project folder when you save a Set somewhere that is not already a project. Save into one that exists and it does not: the Set joins that project. Useful when the two Sets are versions of one track. Expensive when they are not.
It takes one click. You are in NIGHTS Project, a new idea arrives, you hit Save As, the dialog opens where you already are, and you type gloss. GLOSS now lives inside NIGHTS Project, as part of NIGHTS.
The cost shows up later. Both Sets share one Samples folder, so a collect from either pours into the same pool. Zip NIGHTS Project to send NIGHTS and you ship GLOSS with it. Delete the folder once NIGHTS is dead and GLOSS’s samples go too.
Spotting it is easy. Look through the folder where your projects live for a Project folder holding .als files whose names have nothing to do with each other. Versions of one track belong together. Two track names in one folder is the trap.
Getting out has an order. Open the stray Set in Live. Save As into the folder where your other projects live, under its own name, so Live builds it a Project folder of its own. Run Collect All and Save so its audio copies into the new folder. Play it, then delete the stray .als from the old project. Do not drag that .als out by hand: that is the move that leaves the samples behind.
The one habit: Collect All and Save
A fresh Set points at samples wherever you found them. That is fine right up until it is not: the pack folder gets renamed, the external drive stays in your bag, and the Set opens with clips it cannot play, hunting for files that are exactly where they always were, just not where the Set last saw them.
Collect All and Save, in Live’s File menu, is the repair for this and the habit that prevents it. Run it and Live copies every external file the Set uses into the project’s own Samples/Imported folder, then re-points the Set at the copies. It asks which kinds of files to bring in, files from elsewhere on your drive, files borrowed from other Projects, and so on. When in doubt, say yes. From that moment the project is self-contained: everything it needs to make sound lives inside its own folder.
When do you run it? Three times, and two of them are the same time. At the end of any session where you dragged in samples from outside the project. Before you archive anything. And before the project leaves your machine, which matters enough that sending an Ableton project to someone else is its own article.
Yes, it copies files, and copies cost disk space. We will get to the arithmetic of that in the cleanup section, because it is the part everyone gets wrong.
One parent folder for all your Ableton projects
Live governs everything inside the Project folder. Where the Project folder itself lives is the one decision it leaves entirely to you, and this is the decision most drives fail.
Make one parent folder. Music/Ableton, D:\Projects\Ableton, wherever your space is. Inside it: a flat list of Project folders. That is the whole structure.
Flat, on purpose. A genre tree sounds organized and is actually a category quiz you have to pass every time you save, and on the nights the idea is actually moving, you will fail it. A flat folder sorted by date modified answers the real questions, what did I touch this week, where is that idea from March, without asking you to remember whether you filed a track under “melodic techno” or “idk dark”. If the list gets long after a couple of years, add year folders and move whole Project folders into them. That move is safe, and we are about to see why.
The habit that makes the parent folder work is almost insultingly small: when Live’s save dialog opens, you go there. Every time. No Desktop, no Downloads, no new stuff 2. A Set saved loose on the Desktop is a Set whose Project folder got built in the one place you promised yourself you would clean up later.
When it is three hundred projects, not thirty
All of that assumes a drive with a bottom you can still see. Plenty of you are somewhere else: a couple of hundred Project folders across an internal drive and an external one, a client folder, and no memory of what half of it holds.
Do not start moving things. Start by counting. Before you invent any structure, get a flat list of every .als you own, from every drive including the one in the drawer, sorted by date modified.
Open File Explorer, click This PC in the sidebar so the search covers every drive, then type this into the search box in the top right:
ext:.als Sort by Date modified. The top of the list is what you actually work on. The bottom is the archive you did not know you were keeping.
On macOS, mdfind -name .als in Terminal does the same. The count is always higher than the guess.
Then three states, and three is the ceiling: in progress, finished, archived. Three folders in the parent, whole Project folders moved between them, nothing else. Every extra state is a decision you make at the moment you want to stop working. “Nearly done”, “needs vocals” and “on hold” all mean the same thing, which is that you stopped, and once two states mean the same thing, sorting by them tells you nothing.
Archived does not mean buried. Keep archived projects in the same parent folder under the same naming scheme, with one entry condition: nothing gets archived until Collect All and Save has been run on it. An archive is a promise that it still opens in five years, and a project pointing at a pack you uninstalled in 2023 cannot keep it.
Here is where it turns. At three hundred projects, a folder tree is doing the only thing a folder tree can do, which is store. The questions you have at that scale are not answered by a name: which of these sit at 140, which one still has that vocal take, which need a plugin I no longer own. All of that lives inside the files. A folder name is one string.
That is where Vantom comes in. Point it at the parent folder you just built and it reads every Live project inside, in place: tempo, key, last save, and the plugins each Set loaded, without moving or renaming a single file. That last part is not a detail. Separating a Set from its folder is what breaks it, so an index that rearranged the disk would be undoing the work it exists to make visible. All of them, not the recent handful. Three hundred is a catalog, and that is a different ask.
Naming that survives version fourteen
Name the Set like a title, and keep the version number in the filename: nights_v01.als. When the track moves, Save As into the same Project folder as nights_v02.als, nights_v03.als, and onward. Because sibling Sets share the project’s Samples folder, version fourteen costs you almost nothing on disk. Fourteen Sets, one pool of audio.
Three rules keep the scheme alive. Lowercase, so you never have to remember. Two digits, so v10 sorts after v09 instead of after v01. And the word final is banned, because you have met yourself. final_v3_REAL is not a version number. It is a diary entry.
A quiet warning about Live’s Backup folder: it is a safety net, not a versioning system. It keeps a handful of recent saves and rotates the older ones away without asking. Your _vNN files are the record. The Backup folder is what you check the day something goes genuinely wrong.
Cleaning up without breaking sample references
Here is the rule that makes everything else safe, and the reason this article keeps repeating the word folder: move Project folders whole, never their contents. Live keeps track of collected samples relative to the project, which is why a complete Project folder still works after you move it to a new parent folder, a new drive, or a new computer. The Set looks for Samples/Imported next to itself, and it is there, because it traveled along.
Drag the .als out alone and you have severed exactly that relationship. The Set now sits somewhere its Samples folder is not. Live will do its best, warn you about missing media, and go hunting, but you have converted a working project into a scavenger hunt for no benefit at all.
When a project does come up short, Live’s Manage Files, also under the File menu, is the recovery tool. It shows you which files the project is missing and lets you point Live at a folder to search so it can find them again and repair the references. It is good at finding files that still exist somewhere. It cannot resurrect a file you deleted, which brings us to the deletion question.
Because Collect All and Save copies, it duplicates. Use the same drum break in forty projects, collect them all, and you now own forty copies of that break. At some point you will notice this, feel a deep producerly urge to deduplicate, and consider deleting samples out of Samples/Imported folders to point everything back at one master copy. Do not. That duplication is not waste. It is the price of forty projects that each survive a drive swap, a pack reinstall, and a decade, independently of the other thirty-nine. Storage is cheap. A Set full of dead clips is not.
There is a safe way to reclaim space, and it is built in. Manage Files can show you a project’s unused files, samples sitting in the project folder that no Set in the project references anymore, and let you delete them from there. That, plus deleting entire dead Project folders you are certain about, is the whole approved cleanup toolkit. Everything else is surgery on load-bearing walls.
Templates and the User Library
Everything so far organizes projects after they exist. A template organizes them before they exist. Build a Set with your return tracks, your group busses, your resampling track, your default tuner on the master, and in Live 11 and 12 save it via Save Live Set As Template in the File menu. It lands in your User Library and shows up in the browser, so every new project starts already structured instead of accumulating structure by accident around 4 a.m.
The User Library itself, by default a folder called User Library under an Ableton folder in your documents, is where your racks, default presets, and go-to chains live. In a system where projects are deliberately self-contained and duplicated, the User Library is the one shared, central thing, which makes it the one folder here worth backing up with real paranoia. Projects hold your tracks. The User Library holds your sound.
Staying organized without thinking about it
Now the part that decides it. Everything above is correct, and all of it is habit. Habits hold for weeks. Then a deadline lands, a collab happens over three folders, one Set goes rogue on the Desktop, and six months later you are spelunking through your own drive again. The structure was never the weak point. The maintenance is, because the maintenance is you.
This is where Vantom sits, and it sits carefully. Point its Watched Folders at that parent folder and it indexes every Live project inside, in place. It never moves, renames, or reorganizes a single file. After the section you just read, that is not a modest feature, it is the whole point: moving files by hand is exactly what breaks sample references, so the only library worth running over your projects is one that leaves every Set precisely where Live put it.
On top of the index, every version Live writes becomes a logged entry with a timestamp, which in Ableton means the Backup folder you just met, and Plugin Recognition records which plugins each saved version loaded. Which means “which version still had the old Serum patch” stops being an archaeology dig and becomes something you look up. And if your Ableton parent folder shares a drive with FL Studio and Logic survivors, the cross-DAW version of this whole problem has its own article.
The fifteen minute version
Here is the whole system, compressed into one sitting:
- Create one parent folder, something like
Music/Ableton. Flat inside, no genre tree. - Move your existing Project folders into it. Whole folders only, never loose files out of them.
- Hunt down the loose Sets on your Desktop and in Downloads. Open each one in Live, Save As into the parent folder so Live builds a proper Project around it, then run Collect All and Save to pull its samples home.
- Adopt
trackname_v01.als, Save As within the same Project folder, and retire the wordfinal. - Save a template with your standard session layout so new projects start structured.
- From now on: Collect All and Save at the end of any session that borrowed outside samples, and always before a project leaves the machine.
The folder tree is the storage layer, and after today it mostly runs itself. If you want the layer above it, status, notes, and an answer to “what do I work on tonight”, that is project management shaped like a producer actually works, and it is a different article.
Live has been trying to keep your projects organized since the first time you hit save. Fifteen minutes and one parent folder. Let it.