每个线上音乐协作工具都在回答同一个问题,答案各不相同:两个人同时改项目,会发生什么?
诚实的答案有两种。理解它们,能让你避开选中一个和你乐队对着干的工具。
模型一:版本与 fork
大多数平台——BandLab 的 fork 模型、Splice 的项目历史、任何"上传你的分轨"式服务——都是照着 git 造的,也就是程序员用的那个工具。你取一份项目副本,在副本上干活,发布成一个新版本。别人也这么干。然后得有人来合并。
程序员接受这笔交易,是因为合并文本是可解的:两个人改了不同的行,git 自动合;真撞上了,你可以把两个版本都读一遍再选。
我用惨痛的方式学到:音乐项目不像文本那样合并。几年前我的乐队在一个基于版本的平台上为公司活动录歌。两个人同时录音,意味着项目的两份副本开始分叉。音乐项目不是一行行文本——它是轨道、clip、淡入淡出、效果链、自动化组成的一个结构,全部互相依赖。不存在一份可以并排读的 diff;你只能靠耳朵重建两边各改了什么,再把其中一边手工重做一遍。歌最后是做完了,但合并花掉的晚上比录音还多。
公平地说,版本模型有真实的长处:版本是天然的存档点,fork 让陌生人不碰原作就能 remix 你的曲子,而建立在它之上的平台这些年也补上了实时会话功能(尤其是 BandLab,现在编辑器里已经有实时协作)。如果你的协作是素未谋面的人之间的异步 remix,fork 就是正确的形状。
模型二:一个活着的项目
另一个模型靠从不让副本分叉来跳过合并:只有一个项目,每个人的修改在发生的那一刻就落进去。Google Docs 就是这样杀死邮件里的 essay_final_v3.doc 的,Figma 也是这样改变设计工作的。没有人再合并文档;文档就是当前的。
TuttiDAW 从地基起就建立在这个模型上,用的是同一类技术(无冲突复制数据,也就是 Figma 式多人协作背后的那套思路)。实践里这意味着:
- 两个人同时录音,两条录音落进同一个项目、各自的轨。事后没有任何需要调和的东西。
- 你听到的项目状态就是项目状态——不是一个可能落后于某人未发布 fork 的版本。
- "把最新的工程发我一下"从此不再是一句有人会说出口的话。
代价朝另一个方向跑:你放弃了整齐的命名版本历史(TuttiDAW 的 Local Studio 对此的回答,是把项目存成普通文件夹,你可以自己放进 git——想要存档点就有存档点,没有强加给你的合并),而且一个实时共享的项目更适合彼此信任的乐队,而不是一万个 remix 热单的陌生人。
怎么选
问你们这群人实际在干什么:
- 陌生人互相 remix 公开曲目 → 版本模型。fork 就是为这个存在的。
- 一群固定的人一起把歌做完——乐队、合唱团、共同制作人、播客搭档 → 实时模型。你们的问题不是分发,是迭代速度,而合并是压在每一次迭代上的纯开销。
如果你在第二群人里,那 TuttiDAW 就是为你们做的。开一个项目,把人拉进来,"合并"这个词从此不会出现。