Every online music collaboration tool answers one question differently: what happens when two people change the project at the same time?
There are two honest answers. Understanding them will save you from picking a tool that fights your band.
Model one: versions and forks
Most platforms - BandLab's forking model, Splice's project history, any "upload your stems" service - are built like git, the tool programmers use. You take a copy of the project, work on your copy, and publish it as a new version. Someone else does the same. Then somebody merges.
Programmers accepted this trade because merging text is tractable: when two people edit different lines, git combines them automatically, and when they collide, you can read both versions and choose.
I learned the hard way that music projects don't merge like text. A few years ago my band recorded a song for a company event on a version-based platform. Two people recording at once meant two diverging copies of the project. A music project isn't lines of text - it's a structure of tracks, clips, fades, effect chains, and automation, all interdependent. There's no side-by-side diff you can read; you reconstruct both sets of changes by ear and redo one of them by hand. We finished the song, but the merging cost more evenings than the recording did.
To be fair, the version model has real strengths: versions are natural checkpoints, forks let strangers remix your track without touching the original, and platforms built on it have added live-session features over the years (BandLab, notably, now has real-time collaboration in its editor). If your collaboration is asynchronous remixing between people who've never met, forks are the right shape.
Model two: one live project
The other model skips merging by never letting copies diverge: one project, and everyone's edits land in it as they happen. It's how Google Docs killed the emailed essay_final_v3.doc, and how Figma changed design work. Nobody merges a document anymore; the document is simply current.
Joint is built on this model from the ground up, using the same class of technology (conflict-free replicated data, the approach behind Figma-style multiplayer). What it means in practice:
- Two people record at the same time and both takes land in the same project, on their own tracks. There is nothing to reconcile afterwards.
- The project state you hear is the project state - not a version that might be behind someone's unpublished fork.
- "Send me the latest session" stops being a sentence anyone says.
The trade-offs run the other way: you give up the tidy named-version history (Joint's Local Studio answers this by storing projects as plain folders you can put under git yourself - checkpoints when you want them, no merges forced on you), and a live shared project suits a band that trusts each other more than it suits ten thousand strangers remixing a hit.
How to choose
Ask what your group actually does:
- Strangers remixing each other's public tracks → version model. Forks exist for exactly this.
- A fixed group finishing songs together - a band, a choir, co-producers, podcast co-hosts → live model. Your problem isn't distribution, it's iteration speed, and merging is pure overhead on every iteration.
If you're in the second group, that's who we build Joint for. Open a project, invite your people, and the word "merge" never comes up.