Wit has never been verified to produce a file that a DAW will actually open. Everything else in the project is downstream of this: if a merged or restored .als is rejected by Ableton Live, the design does not work.
What we know today
docs/EXPERIMENTS.md §5 records a clean 3-way merge of two disjoint edits that produced a structurally valid, re-gzipped 431 KB .als. It parses as XML and round-trips. It has never been opened in Live, because no DAW was launched during the research.
The task
- Reproduce the merge from EXPERIMENTS.md §5 (base = save 5, "Alice" = save 6, "Bob" = save 5 with one different track's volume changed).
- Open the merged file in Ableton Live.
- Report: does it open? Are both edits present and correct? Any warnings, missing devices, or silent data loss?
- Repeat for a file that has only been round-tripped (gunzip → gzip, no edits) to isolate whether any failure comes from merging or from repacking.
Why this is a blocker
If round-tripping alone corrupts a set, that is a much more fundamental problem than merge semantics, and we need to know which one we have.
Please report the exact Live version. Do not test on work you care about — copy the project first.
Wit has never been verified to produce a file that a DAW will actually open. Everything else in the project is downstream of this: if a merged or restored
.alsis rejected by Ableton Live, the design does not work.What we know today
docs/EXPERIMENTS.md§5 records a clean 3-way merge of two disjoint edits that produced a structurally valid, re-gzipped 431 KB.als. It parses as XML and round-trips. It has never been opened in Live, because no DAW was launched during the research.The task
Why this is a blocker
If round-tripping alone corrupts a set, that is a much more fundamental problem than merge semantics, and we need to know which one we have.
Please report the exact Live version. Do not test on work you care about — copy the project first.