共享轨迹与独占声对象：WeSp 如何把协作式空间化拆成可同时编辑的结构

英文题目：Shared Agency through Collaborative Trajectory Editing in Immersive Audio .

会议身份：conference:nime:2026:conference-paper-id:nime2026_141

✅ 来源为官方会议 PDF；表格与 Figure 按原文证据绑定。PDF 公式以原页区域图片展示，未冒称作者原始 TeX。

会议来源：官方记录 · 官方 PDF

标签：#软件工具 #用户研究 #空间音频信号 #空间音频渲染

评分：7.0/10 | 创新 1.2/2 | 技术严谨 1.0/1.5 | 实验充分 0.8/1.5 | 清晰度 0.8/1 | 影响力 0.7/1.5 | 开源 1.2/1.5 | 可复现 0.3/0.5 | 工程/实践 1.0/1.5

排名：前50% | 文档类型：系统技术报告

👥 作者与机构

• Lennart Sailer：机构信息未能从会议 PDF 纯文本可靠映射
• Henrik von Coler：机构信息未能从会议 PDF 纯文本可靠映射

📌 核心摘要

沉浸式音频多人实时协作轨迹编辑面临输入冲突、视听映射失配与协同意图难对齐的难点，单用户时间线自动化难以直接扩展到现场合奏与即兴表演。WeSp以浏览器共享三维场景为输入，先经共享样条轨迹层同步集体空间结构编辑，输出所有用户可见可改的轨迹集合。再经个人声音对象播放头控制，将上一步轨迹集合作为运动约束，实现沿任意轨迹的速度、方向与定位操作。最后经中央服务器双向通信转开放声音控制消息，驱动外部高阶Ambisonics渲染输出。与已有单用户轨迹工具的关键机制差异在于轨迹结构共享而声音对象独占，从而在保持个人演奏连续性的同时实现空间布局的相互可修改性。在平板与笔记本分组比较条件下，Plan Events条目的Mann-Whitney U指标为8.50，低于Connected条目的Mann-Whitney U指标28.00。该结论适用边界受限于共处协作与视觉主导的即兴场景，难以推广到远程无言语协调或高密度声源下的听觉可分性。原文未披露训练、推理或部署成本。

🔗 开源与复现资源

• 代码相关资源：https://github.com/koyi8/WeSp — 链接可访问（HTTP 200）
• 复现相关资源：https://github.com/koyi8/WeSp — 链接可访问（HTTP 200）
• 第三方资源：https://www.iannix.org/en/ — 链接可访问（HTTP 200）
• 第三方资源：https://gmem.org/holophon — 链接可访问（HTTP 200）
• 第三方资源：https://zkm.de/en/about-the-zkm/organization/hertz-lab/software/zirkonium — 链接不可用（HTTP 404）
• 第三方资源：https://grapes-3d.com/ — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么，目标是什么，本文要解决什么协作缺口？

本文的输入是沉浸式音频研究与教学中常见的工作方式：研究者或学生已经会用声源定位、自动化包络和多声道渲染，但想让多个表演者同时塑造声音在空间里的运动。本文的目标读者是刚进入语音、音乐与音频领域的研究生，需要先建立可复述的事实链：任务是什么，系统做了什么，实验在什么条件下测了什么。

必须保留的信息包括系统名 WeSp、基于浏览器、多用户共享轨迹、每人独占声对象、4 组 16 人实验、两种平板与笔记本设备、21 声道 Ambisonic 穹顶、用户体验问卷与声音交互问卷的组合评估。最终输出是 1 篇按学习依赖展开的技术解读，不做超出原文的性能承诺。沉浸式音频里的空间运动常被组织成轨迹，也就是声源随时间走过的路径。轨迹的好处是把位置、速度、方向这些时空属性写成可视、可编辑的线，过去走过哪里、未来要去哪里都能看见。

这与电子音乐制作里常见的参数自动化是同一思路的延伸：把随时间变化的东西画出来、存下来、再演出来。对象式空间化把每个声源当作离散实体，靠向量幅度平移、高阶 Ambisonics 或波场合成等渲染算法摆到空间里，轨迹则规定实体如何随时间演化。论文指出这类工作流在听觉上有一个约束：只听声音很难分辨和跟踪复杂轨迹，所以需要视觉表征辅助定位和轨迹感知；同时轨迹编辑精确但不天然适合表演，更关键的是以往系统多为单用户，不支持共享编辑。

在多人同时操控的沉浸场景里，这就成了共享能动性的缺口：复杂性本适合协作，但工具不允许协作。

已有路线做到哪里，为何还是单用户为主？

相关工作可以按输入、目标、监督与运行阶段来对照。第一条路线是对象式空间化，输入是离散声源与渲染算法，目标是把声源摆准、动顺，运行阶段多为数字音频工作站里的插件或独立应用，交互是时间线自动化或参数编辑，优点是精细，代价是实时操控与现场表演的自由度有限。第二条路线是轨迹式界面，早期如 70 年代用算法生成无可视化的声音路径，后来出现 Holo-Edit、IanniX、Zirkonium 等图形环境，可以设计和执行空间轨迹。

IanniX 用曲线、触发器和游标形式化轨迹，支持确定性与生成性行为并可接外部媒体与控制；更近的 Grapes 强调现场交互，提供可编辑的轨迹预设与速度、方向、路径切换的实时控制。还有一些系统加入随机运动、群集或手势操控。但论文明确指出这类界面仍以单用户为主，对协作编辑与共享控制支持有限。

第三条路线是协作式空间音频应用，包括桌面 tangible 界面、SoundXY4 把方块旋转与位置映射为 Ambisonic 声源、网络化多媒体乐器、虚拟现实与增强现实中的协作演奏，以及用嗓音起笔绘制轨迹的 Invoke、支持双耳距离渲染与可绘制轨迹的 INVISO。教学例子：可以把单用户轨迹系统想象成一个人拿笔在地图上画公交线，协作系统则是 4 个人同时改同一张线路图，还要各自开自己的车不撞车。已有协作研究强调的要点是相互感知、共享一致表征、可相互修改与共享标注，这正是 WeSp 要补的部分。

对象式空间化 × 轨迹式控制： 对象式空间化把每个声源看作可在空间中定位和移动的离散实体，负责回答声源是什么、在哪里；轨迹式控制再规定声源随时间经过的路径，负责回答声源如何运动。两者搭配是因为仅有定位缺少时间演化，仅有路径缺少承载声音的实体，组合后形成声对象沿轨迹运动的自动化扩展，既能做精确编排也能做实时表演。

WeSp 把协作问题具体化成什么可操作的设计问题？

论文把大问题收敛为一个研究问题：WeSp 的交互设计如何支持共享能动性。操作化之后，它变成两个可执行的分离：空间结构层是否可以被所有人同时改，时间行为层是否保留个人控制。为此系统提出两类原语：轨迹是可编辑的样条曲线，作为空间路径；声音对象是沿轨迹运动的播放头，可调播放速度与方向，也可手动摆放到任意轨迹上。这种分离的用意是把需要协商的集体舞台与不该互相干扰的个人乐器分开。

评估也围绕该问题组织：先做结构化任务让人熟悉初始化、静态分布、动态汇聚、轨迹创建与修改，再做开放即兴看群体如何自组织，最后用通用体验问卷、声音交互问卷与开放回答的 3 类证据回答可用性与协作策略。需要提醒初学者：本文不训练神经网络模型，也不做语音识别或分离指标，问题域是人机交互与空间音频创作工具，不要用检出率或信噪比的直觉去套它的结果。

WeSp 全景：谁改什么，谁不许改什么？

WeSp 是一个基于浏览器的应用，多用户通过网页界面连到中央服务器，在同一会话里交互。实现用 JavaScript 加 HTML 与 CSS 做结构与样式，客户端与服务器之间用双向 WebSocket 交换交互数据，动作发给服务器再分发给所有客户端以保持共享状态一致。输出侧把交互数据在服务器端转成开放声音控制消息，转发给外部音频渲染环境，保持界面与具体渲染解耦。本文实验用 Reaper 会话做渲染与回放，更多实现细节指向伴随代码仓库。

数据分两类：共享数据按变化同步以省网络开销，用户特定数据连续更新以支撑实时交互与动画。协作设计如图 2 所示，所有共享轨迹可被任何用户操控，个人只控制自己的播放头，每个播放头可跟随任意轨迹。为了帮助理解，先沿一个样本走完全程：某用户在 3D 视图里拖动一条轨迹的控制点，改动经 WebSocket 发到服务器并广播，所有人看到同一条线变形；接着该用户把自己的声对象切到这条轨迹并加快速度，声音在穹顶里的运动随之变化，但别人的声对象不受影响。

颜色编码区分用户，自己的对象更大并带实时信息，别人的对象半透明缩小，既认得出自己，也看得见全局。

共享轨迹 × 独占声对象： 共享轨迹负责定义空间结构，也就是所有人都能改的 3D 样条路径层，它承担集体创作的舞台搭建工作；独占声对象负责承载时间行为，也就是每个人只控制自己的播放头沿轨迹走多快、朝哪走。两者搭配的理由是避免多人同时抢同一个声源造成冲突，又保留对整体空间的共同塑造，组合后形成分布式共享能动性：结构共治，行为自治。

下面先建立交互概念的整体图像，再用图解释共享与独占箭头的含义。该图是理解全文机制的关键，因为后文所有协作行为都发生在这个分工之上。

看图路径： 1. 先找到中间标有 Shared trajectories 的方框，确认它是所有箭头指向的共享层；2. 再对比灰色 shared control 箭头与彩色 exclusive control 箭头各自的起点和终点；3. 接着沿虚线 follows any trajectory 看每个声对象如何挂接到任意轨迹；4. 最后数四角小人与四个声对象的颜色对应关系

论文图 2。原论文 Figure 2：“Interaction concept of WeSp: all shared trajectories can be manipulated by any user (gray arrows); each user controls only their individual play-head (solid colored arrows); each…”。

该图中间是共享轨迹池，四角是 4 个用户与各自独占的声对象。灰色共享控制箭头都指向中间，表示任何人都能改结构；彩色独占控制箭头只连向自己的方块，表示行为不互相抢；虚线跟随箭头表示声对象可挂到任意轨迹。像素上可看到 4 种颜色的小人与方块一一对应，中间有多条交叠的黑色轨迹线。这种画法把共享能动性翻译成权限设计：共治的是路，自治的是车。

轨迹、声对象与 3D 视图各自算什么、怎么动？

轨迹是可编辑的样条曲线，支持在 3D 视图里直接拖拽，也支持滑杆与按钮做精确调整与触屏表演。声对象是沿轨迹运动的播放头，行为控制包括调速、改方向、手动定位到任意轨迹，从而把空间结构与时间行为分开。3D 场景同时显示轨迹与声对象，自己的对象强调尺寸与实时信息，别人的对象降低视觉权重以保持整体感知。图 1 展示了两个联网用户各自聚焦不同轨迹时的共享 3D 场景，是理解视觉协调作用的直接证据。阅读时注意它不是渲染效果图，而是协作时真实看到的带控制点、坐标与网格地面的工作视图。

看图路径： 1. 对比左右两幅视角中被加粗强调的轨迹颜色有何不同；2. 观察大方块与小线框方块的尺寸和透明度差异；3. 查看轨迹旁边标注的三维坐标数字与 P1 至 P4 控制点；4. 注意下方网格地面作为空间方位参考的作用

论文图 1。原论文 Figure 1：“Shared 3D-Scene for two connected users, each focusing a different trajectory.”。

从像素看，左右两幅视角共享同一组绿色、粉色与青色轨迹，但加粗强调的轨迹不同，左侧加粗绿色轨迹，右侧加粗粉色轨迹。大实心方块是当前视角所属用户的对象，带 3 维坐标数字标注，小线框方块是他人对象。灰色小方块是轨迹控制点，P1 至 P4 标记路径节点，下方网格提供方位参考。这种不对称强调正是论文所说的个体能动性加相互感知：场景一致，但每人视角突出自己的操作对象。

客户端服务器架构 × WebSocket 双向通信： 客户端服务器架构负责维护一份一致的共享会话状态，所有浏览器客户端都连到中央服务器；WebSocket 双向通信负责低延迟地交换交互数据，改轨迹就同步，播动画就连续更新。两者搭配是因为浏览器天然分散，需要一个权威状态源加实时通道，组合后实现多人在同一 3D 场景里同时编辑而不各玩各的。

本研究训练了什么，没有训练什么？

本研究没有训练任何神经网络模型，也就没有梯度路径、参数冻结与更新、损失函数或早停需要交代。初学者不要把无训练等同于系统输出确定：轨迹形状、播放速度、方向选择与多人同时操作都会改变声音结果，输出仍随交互而变。真实的计算过程是工程与交互流程：浏览器端采集编辑与播放控制，经 WebSocket 发往中央服务器做状态合并与分发，再由服务器转成开放声音控制消息驱动外部渲染；共享轨迹按变化事件同步，用户特定动画数据连续更新。

构造过程是任务序列的设计：从单声对象初始化、静态分布、分组定位，到动态汇聚、等距再分布、轨迹创建与修改，最后是短曲即兴。评估侧的计算是问卷统计与主题分析：用户体验问卷看 6 个维度相对基准的位置，声音交互问卷比较平板与笔记本两组，开放回答做主题分析提炼协作模式。缺项要明确指出：原文未报告网络延迟、帧率、中央处理器占用或渲染开销，无法从浏览器加 WebSocket 的字面实现推定实时性一定满足大规模演出。

实验在什么房间、用什么设备、按什么步骤测？

实验在受控多声道工作室进行，配备 21 只扬声器的 Ambisonic 穹顶。4 组共 16 人参加，每组 4 人，背景多为音乐或声学相关，每组同时使用两台笔记本电脑与两台平板电脑，均运行浏览器界面。组内围坐在扬声器系统中的桌旁，每人控制一个循环采样声源，协作阶段共享由 4 个循环采样构成的空间声景。会话约 1 小时，分为界面介绍、个人探索、协作任务与即兴、调查问卷 4 个阶段。

协作任务分四期组织：初始化与静态空间化、动态协同、轨迹编辑、创意应用，从逐个创建声对象、关闭动画摆位置、分组搬到指定区域，到开启动画汇聚成一点、等距再分布并随速度方向互相反应，再到新建轨迹加点、改形状闭合与张力并重指派对象，最后用全部功能即兴一小段。问卷在 LimeSurvey 浏览器端完成，包括开放问题、原版用户体验问卷与修改版声音交互设计问卷。

修改版声音交互问卷用 8 条：与声音变化的连接感、动作与声音效果的对应、可规划空间事件、参与创作过程感、控制感、挑战性、反馈可理解性、对所做空间化的喜欢程度。开放问题共 10 条，覆盖协作体验、共享能动性做法、投入感、意外得失、有效策略、最有用功能、协作困难、与他工具差异、现场演出意愿与改进建议。 下面用两张宽表把人员设备条件与时间流程固定下来，便于复现时逐项核对。

第一张回答谁、在哪、用什么、听什么、测多久的公平条件问题，所有数字与单位均保留原文写法。

该表把最容易混淆的基数 1 次讲清：组数与人数决定协作密度，4 台异构设备决定输入方式对比，21 声道穹顶决定空间分辨率，4 个循环采样决定声源数量，会话时长决定任务深度。

后文所有问卷差异都应在这个条件下理解，不能推广到远程或更大编制。 第二张回答时间如何切分的问题，协作与问卷各占多少直接影响结论权重。

该表显示协作是主体，介绍与个人探索很短，因此可用性结果更偏向短时上手后的协同体验，而非长期训练后的专家表现。5 分钟即兴是观察自组织策略的关键窗口，问卷 20 分钟则为开放回答留出空间。

可用性与声音跟手感测得什么，哪里出现设备差异？

参与者 16 人，年龄 25 至 68 岁，音乐背景占 75%，声学背景占 62.5%。用户体验问卷在所有维度均为正向，吸引力与刺激性达到优秀区间，平均值高于 0.8 表示明确正向，所有维度相对基准数据集都在平均以上，新颖性维度个体差异相对较大。声音交互问卷总体显示动作与声音的连接感、动作与声音效果的对应感较高，控制感与空间化喜欢度也偏正向。设备比较只在规划空间事件一项出现统计显著差异，笔记本用户评分更高，论文据此推测指针交互与更大屏幕更利于精确空间规划。图 4 把用户体验问卷的均值与置信区间放在基准色带里，是判断好坏方向的关键：越高越好，落入深绿即优秀。

用户体验问卷 × 声音交互设计问卷： 用户体验问卷负责评价一般交互产品的吸引力、易学性、效率等通用维度，并与基准数据集比较；声音交互设计问卷负责评价动作与声音变化的连接感、空间事件规划感和控制感。两者搭配是因为通用可用性不能替代声音特有的因果感知，组合后才能同时回答系统好不好用和声音跟手不跟手。

在看图之前，需要明确比较对象不是两个 competing 算法，而是同一系统在异构设备上的表现，基准是通用交互产品的历史分布。

看图路径： 1. 先读横轴六个维度名称，再看纵轴得分范围；2. 对比每个维度黑色菱形均值点落在哪个颜色基准带；3. 观察误差线长度，判断哪个维度个体差异更大

论文图 4。原论文 Figure 4：“UEQ results: Scale means with confidence intervals in relation to the benchmark dataset.”。

像素上横轴为吸引力、明晰性、效率、可依赖性、刺激性、新颖性 6 个维度，纵轴为得分，黑色菱形为均值，竖线为置信区间，背景红橙浅绿深绿分别对应差、低于平均、高于平均、好与优秀。可以看到吸引力与刺激性均值落在深绿优秀带，其余多在浅绿以上，新颖性均值相对较低且区间较长，与正文所说新颖性变异较大的判断一致。 下面呈现设备比较的定量结果表，它是本文唯一的推断统计表，保留原表全部行列与精度，不做差值或换算。表前要提出比较问题：在动作声音连接、规划、控制等 8 个条目上，平板与笔记本是否一致，指标方向为得分越高表示越认同，挑战性条目高分表示更具挑战。

该表显示只有规划事件一项的显著性水平达到 0.011，其余各项均未达到常规显著阈值，效应量也以该项最高。这支持笔记本更利于空间规划的有限解释，但不能推广为笔记本全面优于平板。未胜出项本身就是信息：连接感、声音效果、创作过程、控制感、反馈与喜欢度在两设备间基本一致，说明核心跟手感跨设备稳定。同时要指出样本仅 16 人、每设备组 8 人，检验力有限，显著结果需谨慎看待。

去掉语言协调或换交互密度，结果还成立吗？

本文没有做去掉某模块的消融实验，因此只能用任务阶段与开放回答中的反例来讨论边界条件。结构化任务中投入感普遍较高，开放即兴中当声源掩蔽加重、系统活动变密时，有人出现投入下降与个体存在感丢失。这说明共享控制的收益依赖交互密度：适度重叠促进同步与模仿，过度重叠增加注意负荷。语言协调是另一条边界：在同室工作室里，言语是建立共同意图、协商动作的主要手段，还伴随同步运动、模仿他人、暂时收手观察等非言语策略。

如果移到远程或演出场景而拿掉言语，现有结论不一定成立，需要界面内置的协调机制替代。图 5 按设备拆分 8 个声音交互条目，可用来检查差异是否只集中在规划项，还是普遍存在。

看图路径： 1. 先按横轴八个问题找到 Plan Events 那一组柱形；2. 对比同一问题下蓝色平板与黄色笔记本电脑箱体的位置高低；3. 注意方形均值点与横线中位数的分离情况；4. 查看 Challenging 一组的得分整体偏低现象

论文图 5。原论文 Figure 5：“SIDQ results for tablet and laptop users. Squares indicate means, lines indicate medians; outliers are marked as dots.”。

像素上横轴为 8 个问题，纵轴为 1 至 5 分，蓝色为平板，黄色为笔记本，方块为均值，横线为中位数。可执行观察是先看规划事件一组黄色箱体整体高于蓝色，再看创作过程一组蓝色分布拉得很长而黄色集中偏高，最后看挑战性一组两设备中位数都偏低。这与统计表相互印证：差异集中而非全面，挑战感整体不高，创作体验的个体差异在平板端更大。

视觉帮忙在哪里变成听觉负担？

论文明确报告的局限首先是听觉区分难：有人难以从多人混音中分辨自己的声源，尤其在密集交互时。这与视觉依赖形成张力：大家靠共享视觉表征保持 awareness，看彼此动作并调整自己，但过度依赖视觉可能进一步降低个体声音贡献的显著性，声源越多越难跟踪自己。原文把这称为视觉协调与听觉区分的 tension，并联系电子音乐中可视化分散听觉注意力的已知问题。

其次是输入与显示差异：精确空间规划在触屏上不如指针加大屏顺手，这既是交互精度问题，也是屏幕尺寸与视觉表征可读性问题。第三是协调机制的场景依赖：同室言语有效，但远程或演出中言语受限，需要手势、视觉信号或共享状态等替代机制。第四是样本与生态局限：16 人多为音乐与声学背景，单次短时工作室任务，不能代表新手、非音乐人或长期乐团排练的表现。

共享视觉表征 × 听觉反馈： 共享视觉表征负责让所有人的轨迹修改和对象位置可见，承担协调与定向功能；听觉反馈负责让人确认自己动作造成的具体声音变化。两者搭配的理想状态是所见即所听，但在多人密集活动时视觉信息压过了听觉区分度，组合后暴露出多模态负荷问题：看得清彼此，却听不清自己。

对初学者的提醒是：缺失证据不是技术错误，没有测延迟、误判率或长期学习曲线，就不要承诺这些量得到改善；相关性也不是因果，视觉好用与协作顺畅同时出现，不等于视觉直接导致音乐更好。

要复现这套协作实验，先准备什么、按什么顺序做？

复现分系统与实验两条线。系统线按仓库与第三方工具的可达状态准备：代码与复现仓库当前可用，地址为 github 上的 WeSp 项目，可核对实现细节与 Reaper 会话配置；IanniX、Holo-Edit 对应站点与 Grapes 站点当前可用，可用于理解轨迹式路线；Zirkonium 在原文给出的 ZKM 地址当前不可用，写链接当前不可用，不要再按该地址去找。第三方渲染可用 Reaper 会话替代，输出经开放声音控制消息转发，保持界面与渲染解耦。

实验线按原文条件摆齐：21 声道穹顶或等效多声道环境、每组 4 人共 4 组、每组两台笔记本加两台平板、4 个循环采样、约 1 小时流程。顺序是 6 分钟介绍、4 分钟个人探索、30 分钟协作任务加 5 分钟即兴、20 分钟问卷。任务从静态摆位到动态汇聚再到轨迹增删改，最后开放即兴。测量用原版用户体验问卷加 8 条修改版声音交互问卷，开放 10 问做主题分析。统计时注意用户体验问卷看相对基准的位置，设备比较用 Mann-Whitney U 检验并报告效应量。

先做最小可运行验证：2 人同时改同一条轨迹并各自控声对象，确认状态一致与声音跟随，再扩到 4 人全任务。

何时值得尝试 WeSp 式分工，还缺哪项验证？

当教学或演出需要多人同时塑造空间运动，又不想互相抢声源时，值得尝试共享轨迹加独占声对象的分工：把路共治，把车自治，用颜色与尺寸区分彼此，以共享视觉对齐行动。复现时先保证网络同步与渲染链路可用，再按原文任务密度组织协作，最后用同样的问卷组合评估，避免只看好评而忽略听觉区分与视觉负荷。

还需补的验证包括远程无言语条件下的协调机制、大编制与长时间排练下的注意负荷、触屏精确规划的改进交互，以及延迟与系统开销的量化测量。回到中心判断：WeSp 的贡献不是更准的定位算法，而是一种可执行的协作权限设计，让共享能动性从口号变成谁能改什么的规则，并在小样本工作室实验中显示可用与可学，但密集场景的听觉清晰度仍待解决。

📐 原文公式与排版

以下展示论文原页中的数学表达区域，保留原始上下标、分式和符号排版。区域序号仅用于本文导航，不是论文公式编号。

另有 3 个候选区域因边界不明确或图片数量、尺寸限制未展开；请查看完整论文中的原始排版。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1
• 评分模型：muse-spark-1.3-contributor
• 评分请求协议：openai_responses

← 返回 nime-2026 论文汇总