用文件名管住调性与速度：MBHD 的四轨循环表演系统

英文题目：MBHD: A Modular Audio Playback and Manipulation System for Loop-Based Performance

会议身份：conference:icmc:2026:conference-paper-id:paper-15

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

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

标签：#信号处理 #用户研究 #实时处理 #音乐 #音频交互

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

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

👥 作者与机构

• Neal Anderson：机构信息未能从会议 PDF 纯文本可靠映射
• Sanjay Majumder：机构信息未能从会议 PDF 纯文本可靠映射

📌 核心摘要

该系统输入为散乱收集的鼓组贝斯和声与旋律循环音频，输出为锁定全局速度与调性的多路混音，实际难点在于跨曲库循环的节拍与调性难以在演出中同步对齐，人工逐一修改元数据耗时且限制即兴发挥。文件名解析先从结构化命名中抽取速度根音与乐器角色并写入字典映射，字典随即作为中央查找表驱动缓冲加载与声部分流，使后续处理能即时获得音高与速度属性。全局走带与时间伸缩引擎再按速度比调整可变速播放并以小节为单位保持相位对齐，使各层循环跟随统一走带时钟而不互相干扰。谐波一致引擎计算全局调与解析根音之间的半音差并经平滑后送入频域移调与重布线混音，实现变速不变调与变调不变速的独立控制。相比依赖手标元数据与嵌套菜单的数字音频工作站，该机制以命名约定替代人工标注并保持多路并行可重布线，把演出稳定性与细粒度即兴控制结合起来。在文件名解析转调任务下，87 A Synth.wav对应律动的移调指标Applied Shift为+5，高于90 C Guitar.wav对应律动的移调指标Applied Shift+4。该结论适用边界仅为十二平均律西方电子风格预录制立体声循环，微分音复杂调式功能与大规模曲库鲁棒性尚未验证，高保真切换会增加延迟而标准消费级硬件可支撑低延迟运行。

🔗 开源与复现资源

• 第三方资源：https://www.roland.com/global/products/sp-404mk2/ — 链接可访问（HTTP 200）
• 第三方资源：https://www.rodrigoconstanzo.com/karma/ → https://rodrigoconstanzo.com/karma/ — 链接可访问（HTTP 200）
• 第三方资源：https://midi.org/ — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么，目标是什么，本文要解决哪一个演出矛盾？

本文的输入是表演者收集的多来源音频循环，包括鼓、贝斯、和声与旋律 4 类立体声 stems，组织为 groove1、groove2 等律动文件夹。每个文件夹内是若干 wav 或 aiff 文件，文件名按约定携带速度、根音与乐器角色信息。输出是经过速度对齐与调性对齐后的立体声混音，可直接用于现场演出，并支持在演出中切换律动、重配声部、改变全局调与速度。

目标读者是刚进入音频技术的研究生，需要先建立一个基本判断：节拍对齐与调性对齐是两件不同的事。前者让循环的长度与重拍对上，后者让不同来源的循环听起来在同一个调上。数字音频工作站与 DJ 软件已经把节拍锁定做得比较可靠，但跨曲库的调性对齐往往要求逐个样本手动编辑元数据或使用第三方工具，既打断创作流，也增加准备负担。

本文要解决的矛盾是 DJ 式演出的结构可靠性与现场电子作曲的表达自由度之间的张力。DJ 式流程追求切歌不断、节奏不乱；现场改编则希望随时换层、换调、做 Dub 式加减法。MBHD 即 Modular Beat Handling Device 的选择是保留一个全局速度与全局调作为共同基准，让 4 路材料都向该基准看齐，同时保留每路独立的变调、声像与音量控制。这样既能一键换律动不乱套，又能在需要时对单路做半音级移调以制造对位或质感变化。

必须保留的信息包括实验条件与适用边界：技术基准在 MacBook Pro M1、16 GB 内存、Max 8、采样率 44100 Hz、调度间隔 1 ms 下测得；浏览器版本只是演示部分设计思想的伴随应用，不复制完整音频循环架构，所有评测只用 Max 实现；当前版本假设 12 平均律，只保证音高类别对齐，不建模和声功能与调式语境。输出是 1 篇可核对的方法复述，不做超出原文的营销判断。

同类路线做了什么，MBHD 把位置定在哪里？

理解 MBHD 需要先看它所处的两端：一端是专业数字音频工作站与硬件采样器，另一端是新乐器界面与实验性循环工具。Max 仍是这类定制演出系统的主要搭建环境。mlr 在 Monome Grid 上建立了现场切片的范式，重心是节奏切片；MBHD 则把重心放在和声一致性上，保证换调时整体律动结构不散。Debris 用颗粒化手段做非线性探索，适合开放音色漫游；MBHD 则为需要稳定脉动与调性的节拍电子乐保留结构化工作流。

硬件方面，Roland SP-404 与 Boss RC-505 一类设备强调触感可靠，但音频常被当作静态材料处理，变调往往要进菜单且易引入明显瑕疵。Ableton Live 一类软件要求手动维护 warp 标记与根音定义才能实现和声匹配。MBHD 的差异是把这部分配置搬到文件名解析，用读文件名自动完成速度比与移调量的初值设定。论文把这种思路与人在回路研究相联系：用户给出的文件名即实时输入，直接配置系统行为。

在 Max 生态内，Karma 擅长采集现场输入并生成演化质感，属于面向输入的循环器；MBHD 则定位为面向预录制 stems 的演出引擎，强调多层之间的确定性和声同步。与 Reflexive Looper 或 The Living Looper 等关注循环体之间相互作用的智能体路线不同，MBHD 强调由表演者主导的编排。论文还引用了关于快速反馈与空间一致性、避免嵌套菜单、减少映射混淆的讨论，解释了为什么界面要做成 1 对一参数映射与 DJ 调音台式布局。

这些对照的公平含义是输入、目标与运行阶段并不相同，不能直接比出胜负。硬件的可靠性在触感与稳定性上成立，软件的灵活性在编辑精度上成立，实验性系统的创新在交互形式上成立。MBHD 的可尝试场景是曲库庞杂、需要频繁换律动且不希望逐个样本手动定调的节拍演出；若演出核心是现场录音叠加、颗粒质感或微分音体系，则需要另选工具或改造其 coll 数据结构。

为什么多来源循环一混就容易调性打架？

举一个教学用的例子而非原文数据：假设表演者准备了 3 段循环，鼓循环标记为 90 拍、和声循环原调是 C、贝斯循环原调是 G，而今晚演出定的全局调是 E。如果只做速度对齐，3 段节奏能对上，但和声与贝斯的根音与全局调不一致，听感上会出现持续的调性冲突。传统做法是提前在工作站里逐个试听并手动移调，或在演出中凭耳朵拧变调旋钮，前者费时，后者容易在台上出错。

问题的难点在于信息缺失与操作时机。循环文件本身的采样数据不直接告诉系统它是什么速度、什么调、该送哪一路处理。文件格式与标签可以携带一部分元数据，但跨曲库时格式不统一，表演者仍需整理。演出中又要求低延迟与低认知负荷，没有时间逐轨检查。

MBHD 把问题重新表述为如何用最轻的约定补足这 3 条信息。做法是规定结构化文件名，例如包含速度、根音与乐器名的写法，系统在加载律动文件夹时做字符串解析，把解析结果存入字典作为中央查找表。当文件被装入 buffer~ 时，对应的速度与音高属性立即可用于数字信号处理链。这样做的前提是表演者愿意按约定重命名，而回报是换律动时自动完成初值对齐。

还需要明确两个边界。第一，文件名解析只解决音高类别层面的对齐，不推断和弦功能与调式，复杂调性关系仍需表演者用耳朵判断。第二，系统依赖命名约定，遇到不符合约定的文件只能走回退逻辑，可能带来错误的和声结果。这两个边界决定了后文的验证逻辑：既要测正常命名下的对齐与性能，也要说明命名缺失时的默认行为。

系统全景：四路并行加一个全局基准如何协同？

MBHD 的总体安排是模块化并行处理框架，把音频播放与具体的处理逻辑解耦。鼓、贝斯、和声与旋律被当作 4 条离散独立的信号链，每条链独立完成读取、变速、变调、声像与音量控制，避免跨通道干扰。4 条声部最后汇总到主混音器，统一增益并做限幅防止削波，再输出为立体声。全局走带时钟是所有模块的中央时间参考，与音频播放速率解耦，使调速不变调、移调不变速成为可能。

沿一个样本走完全程有助于建立整体感。假设用户选中 groove3 文件夹，系统遍历文件列表并解析文件名，得到每个文件的速度、根音与角色；字典记录文件到元数据的映射；角色决定文件进入哪一条轨道的 buffer~；速度决定 groove~ 的播放速率比。

根音与全局调决定变调量；4 路信号经静音矩阵与声像控制进入主混音器输出。切换律动时重复上述过程，演出不中断。 下面先看紧凑的系统架构图，重点是并行声部与全局基准的关系。

看图路径： 1. 先找到左侧四个并列的声部方框，确认鼓、贝斯、和声、旋律四路并行；2. 再看中间全局走带与同步方框向四路发出的控制箭头；3. 最后沿四路汇入主混音器再到立体声输出的主路径走一遍

论文图 1。原论文 Figure 1：“Compact system architecture of MBHD”。

该图显示左侧 4 路声部并行，中间全局走带与同步模块向 4 路发出控制，右侧主混音器汇总后送往立体声输出。阅读时不要把控制箭头误读为音频箭头：全局模块提供的是速度与相位参考，不直接搬运采样；真正的采样只沿各声部向混音器流动。这种分离正是解耦变速与变调的物理基础，也是后文把走带界面与音高界面分开摆放的界面依据。

文件名如何变成可执行的播放参数？

语义数据模型是 MBHD 最具特征的部分。系统不用文件格式与标签作为主要数据库，而是把文件名本身当数据库。当律动文件夹被加载，系统读取文件名并提取三项信息：速度用于决定拉伸或压缩多少时间；根音用于决定源调与目标调之间差多少半音；乐器角色用于决定文件送往哪个处理模块，例如含 Bass 字样的文件进入贝斯链路。解析后的词元存入 dict 字典对象，作为回放引擎的中央查找表。

文件夹层级与命名约定需要具体化。工程侧有 MBHD.maxpat 与 Audio_MBHD 目录，其下是 groove1 至 groove4 等文件夹，每个文件夹内是多轨音频。右侧文件列中可以看到同时携带速度、调名与乐器词的文件名，例如同时出现 90、C 与 Guitar 的写法。解析逻辑按结构化约定拆分文件名，当前实现按 12 平均律把 C、C#、D 等标记映射为 0 至 11 的整数。 下面看文件夹与命名约定的实际截图，体会约定之轻与信息之全。

看图路径： 1. 从左到右看三栏：工程文件、律动文件夹、音频文件列表；2. 核对右侧文件名中同时出现的速度数字、调名与乐器词；3. 观察 groove3 被高亮选中与左侧目录结构的对应关系

论文图 3。原论文 Figure 3：“Folder hierarchy and file naming conventions used for groove- based audio content.”。

该截图左侧是工程与音频根目录，中部是多个律动文件夹并高亮 groove3，右侧是该文件夹内的音频文件列表。可见信息全部暴露在文件名层，无需打开文件即可预判速度与角色。这种透明性降低了准备时的检查成本，但也带来刚性：若文件名缺速度、缺根音或缺角色，系统只能启动回退逻辑。回退时音高默认按 C 调不移调，速度先找可用元数据或启发式估计否则跟随全局速度，角色不明则送往通用辅助总线。回退能防止报错中断演出，但论文明确指出可能导致错误的和声。

文件名即数据库 × 谐波一致性引擎： 文件名即数据库负责从文件名中解析出速度、根音与乐器角色 3 类符号信息，不做音频内容分析；谐波一致性引擎负责把解析出的源根音与全局目标调比较并算出半音差，再驱动变调对象执行移调。两者搭配的理由是把配置信息放在人可直接改的文件名层，使加载新律动文件夹时即可完成路由与移调参数设置，组合后新增的作用是无需手动编辑元数据也能让不同来源的循环自动进入同一调性。

理解回退有助于正确使用系统：正常命名时把它当自动对齐工具，命名不全时把它当需要人工复核的提示，而不是当作全自动识别。

变速、变调与混音链路各自完成什么计算？

每条轨道的回放由专用的 groove~ 对象驱动，看重其可变速播放能力。时间拉伸通过播放速率比实现，速率等于全局速度除以文件速度。同步通过 transport 对象维持，用 phasor~ 或基于触发的重置保证每小节起点相位对齐。空间路由由 gate~ 与 matrixctrl 构成的矩阵管理，配合信号平滑实现低杂音静音与立体声摆位，最终输出级用 limi~ 或乘法逻辑做软削波保护，使 4 路预混母带级循环叠加时不超过 0 dBFS。

独立变调采用频域处理。系统默认用 gizmo~ 基于相位声码器快速傅里叶变换逻辑，保证现场监听的低延迟；也可切换到 retune~ 处理以单声部为主的旋律内容以获得更高保真，代价是约 100 ms 量级的更高负载与延迟。变调量按平均律比率公式计算，由目标调与源根音之差决定，再经 line~ 平滑以避免快速换调时的可闻跳变。和声逻辑用整数运算求半音偏移，并量化到最近整数半音。

谐波一致性处理链是线性 4 步：解析文件名元数据、提取根音、按模 12 计算音级差、经实时变调对象执行。

看图路径： 1. 自上而下跟随四个方框的单向箭头；2. 确认第三步明确写的是半音差计算而非直接写变调量；3. 看最后一步标注的具体变调对象名称

论文图 4。原论文 Figure 4：“Harmonic coherence processing chain: the system parses file- name metadata, computes pitch-class differences, and applies real-time transposition.”。

该流程图自上而下只有一条主路径，没有分支，说明正常路径下每个文件都经历相同的 4 步。教学时应把第三步与第 4 步分开：第三步是符号层计算，输出整数半音差；第 4 步才是信号层执行，真正改变频谱。论文给出的文件名解析表示例说明了同一机制：不同源调的文件在同一全局调下得到不同的移调量，源调与目标调相同时移调为零。

groove~ 播放 × 频域变调： groove~ 播放负责可变速读取缓冲区的立体声采样并按全局速度比调整播放速率，维持循环长度与节拍对齐；频域变调负责在不改变播放时长的前提下改变音高，默认用 gizmo~ 做低延迟相位声码器处理，也可切换到 retune~ 处理单声部旋律。两者搭配的理由是把时间拉伸与音高移动解耦，使速度与调性可分别跟随全局走带与全局调；组合后新增的作用是表演者可以降 12 半音制造持续音质感而节奏仍锁定，这正是用户研究中被提到的新技法来源。

全局走带时钟 × Ableton Link 同步： 全局走带时钟是系统内部的时间基准，负责给出统一的速度与小节相位，并与音频播放速率解耦；Ableton Link 同步负责把该时钟的速度与相位与外部设备或软件对齐。两者搭配的理由是内部需要一个不受变速影响的稳定参考，而外部合奏又需要跨设备的共同参考；组合后新增的作用是 4 路循环之间保持相位对齐的同时，还能与 Ableton Live 或 iPad 上的 Patterning 等外部节点保持长期同步。

4 路模块化声部 × 静音矩阵： 4 路模块化声部指鼓、贝斯、和声与旋律各自拥有独立的读取、变调、声像与音量链路，负责互不干扰地处理一类音乐功能；静音矩阵负责在主混音前快速决定每一轨送往左、右或双声道以及是否静音。两者搭配的理由是独立声部提供了可重组的声音材料，而矩阵提供了演出中一键重配的开关层；组合后新增的作用是实现 Dub 式混音手法，例如抽掉贝斯制造张力或只保留鼓与和声过渡到下一个律动。

界面设计延续了这种分离思想。顶部通道条显示解析出的根音与当前移调区间，便于快速确认解析是否成功；走带控制放在头部并与音高步进器视觉分离，前者是时间拉伸的真值来源，后者支持作曲性移调。每通道后置高分辨率峰值表，同步指示器只给锁定或漂移二值状态，使表演者无需一直监听也能信任 timing 引擎。

本研究有没有训练模型，真正的计算与搭建过程是什么？

本研究没有训练神经网络模型，也就没有梯度路径、参数冻结与更新、监督损失或重置时机的报告。把无训练等同于确定性求解是误解：系统输出仍取决于音频内容、文件名解析结果、全局调与速度的人工选择以及实时操作顺序。缺失的是学习式参数估计，不是可重复性的保证。

真正的构造过程是 Max 8 补丁搭建与原生对象调用。文件管理用 folder 与 umenu 动态索引目录，用字符串解析拆分文件名并写入 dict；回放用 buffer~ 加 groove~；变调在 gizmo~ 与 retune~ 之间可选；路由用 gate~ 与 matrixctrl。

计量用 live.meter~；外部同步用 Ableton Link。补丁面向普通消费级硬件优化，论文提到 Apple Silicon M 系列或 Intel i7 级别，无需外部数字信号处理扩展。

浏览器伴随应用也不是训练产物，而是用基于 MIDI 生成实现的子集演示，覆盖结构化音乐重组、乐器角色抽象与用户驱动交互。它不复制完整音频循环回放架构，因此不能把网页端的体验直接当作 Max 端的性能证据。论文明确要求所有评测只用 Max 实现，网页版因功能缩减未纳入测试。

Max 原型 × 浏览器伴随应用： Max 原型负责完整的四轨音频循环回放、文件名解析、实时变调变速与 Link 同步，是全部评测所用的实现；浏览器伴随应用负责用更易获得的方式演示模块化、乐器角色抽象与用户驱动交互，采用基于 MIDI 的生成而非完整音频循环回放。两者搭配的理由是前者保证低延迟演出能力，后者降低体验门槛；组合后新增的作用是教学与传播时可以用网页说明设计思想，而正式演出与实验结论仍只归于 Max 实现，不把两者性能混为一谈。

复现时应把工作分为 3 类：补丁逻辑复现、命名规范复现与评测条件复现。前两类决定功能是否跑通，后一类决定数字是否可比，缺一不可。

评测在什么机器、什么材料与什么协议下进行？

技术基准的材料是多组律动，每组含四轨立体声音频，长度从 1 小节到 16 小节不等。测试机为 MacBook Pro M1、16 GB 内存，软件为 Max 8，采样率 44100 Hz，调度间隔 1 ms。稳定性测试是 60 分钟自动化压力测试，每 4 小节随机切换场景。同步测试与 Ableton Live 软件及运行 Patterning 的 iPad 联动，观察 30 分钟后的速度漂移。用户研究共 8 人，包括 3 名职业电子音乐人、3 名高阶音乐技术学生与 2 名音频工程师，每人用精选循环库做 10 分钟即兴表演。

指标方向需要先说清。延迟越低越好，中央处理器占用越低越好且要看峰值场景，长时间无掉音说明稳定性，速度漂移越小越好，可用性量表分数越高越好。论文同时报告输入输出环路延迟与算法处理延迟，两者不可混淆：前者含缓冲与调度，后者来自傅里叶窗。 下面看演出界面的实际像素，理解评测中用户真正操作的对象。

看图路径： 1. 先看顶部全局调、速度与 Link 状态行，再看下方四条竖向通道条；2. 核对每条通道上方的音量条、移调数值框与底部角色标签；3. 在右侧找到静音矩阵圆点阵与主音量条的位置

论文图 2。原论文 Figure 2：“MBHD GUI for live performance. Provides full control over groove, pitch, routing, and sync.”。

该界面顶部是全局调、速度与 Link 状态，中部是旋律、贝斯、和声与鼓 4 条竖向通道条，每条含音量条、移调数值与角色标签，右侧是静音矩阵圆点阵与主音量条。布局模仿 DJ 调音台，目的是利用肌肉记忆降低学习成本。评测中用户高度评价的正是无需进菜单即可做 Dub 式加减法的矩阵，以及通道顶部直接可见的解析根音与移调区间。这种所见即状态的设计减少了演出中的检查动作，也是后文可用性得分的机制解释。

延迟、稳定性与同步到底测出了什么数字？

比较问题是系统在满载四轨加实时变调时，能否同时保持低延迟、低占用与长期同步。公平条件是同一台 M1 机器、同一 Max 8 与采样设置、同一类四轨立体声材料；指标方向是延迟与漂移越小越好，占用越低越好，无掉音为通过。

上表把环路延迟与算法延迟分开，是为了避免把 43 ms 误读为整体失同步。原文指出傅里叶窗延迟在信号路径内部，并已做补偿以维持跨轨节奏对齐，不影响走带同步。中央处理器部分的主要收益是满载平均占用控制在 20% 以下，具体代价是同时加载多个大律动文件时会出现 30% 尖峰。同步部分的主要收益是 30 分钟后漂移小于正负 1 ms，但论文也说明这很大程度上来自 Link 协议本身的稳定性，内部调度的作用是防止触发抖动，保证 groove~ 回放的起音始终与下拍对齐。

稳定性方面，60 分钟每 4 小节随机切场景的测试期间未出现掉音与缓冲欠载事件，支持长时间演出可靠性的判断，但未覆盖命名错误、极端文件长度或不同声卡的边界。

未胜出的细节也要保留：retune~ 虽在单声部旋律上保真更高，但延迟与负载更高，默认策略仍是 gizmo~；这是一个用音质换即时性的显式取舍。

用户研究与构造细节支持了哪些判断，又缺了哪块？

比较问题是文件名即数据库与变速变调解耦是否真正降低了准备与演出负担。公平条件是同一精选循环库、同一 10 分钟即兴任务、同一 8 人结构；指标方向是可用性分数越高越好、成功加载时间越短越好、创作新技法报告越多越好。

表后解释需要区分直接报告与有限解释。直接报告的是 86.3 的可用性均值、8 人中有 6 人认为变速变调分离带来新技法、所有用户在 10 分钟内学会加载自定义律动。有限解释是静音矩阵被认为是关键特性，文件命名约定消除了混入走调采样的焦虑。1 位参与者的原意是把打击乐循环降 12 半音做成持续音质感而节奏仍锁定，这在典型硬件循环器上难以做到；另 1 位强调命名约定减少了准备焦虑。这些都支持低摩擦设计的判断，但不能推广为对所有人群与曲库成立。

必须就近说明未评测边界：浏览器版本未纳入测试，不能用网页体验代替 Max 性能；同步精度主要归功于 Link 协议，不能单独证明自研同步算法更优；用户研究无对照组与统计检验，不能得出优于某具体工作站的因果结论；回退逻辑虽能防止崩溃，但可能给出错误和声，该路径未量化误判率。

哪些假设与缺项限制了结论的适用范围？

第一个限制是 12 平均律假设。解析逻辑把调名硬编码为 0 至 11 的整数，适配标准西方电子乐，但要支持微分音或非西方调式必须改 coll 集合数据结构。第二个限制是音高类别对齐不等于和声理解。系统保证进入同一调，但不建模和弦功能与调式语境，复杂调性关系仍可能听感牵强。第 3 个限制是内容准备仍需人工按刚性格式重命名， ingesting 新歌的摩擦依然存在。论文把未来工作指向用 Python 经 node.script 或 py 对象接入音乐信息检索，例如用色度特征估计调与模式、用瞬态检测估计速度、用分类模型区分鼓与旋律并自动路由，但这些在本文中只是方向，没有实现与评测。

第二个层面的缺项是验证口径。技术基准只在一台 M1 机器与固定采样调度设置下完成，未报告不同声卡、不同缓冲、不同文件长度下的分布；用户研究只有 8 人且无对照系统，不能做跨工具胜负判断；同步测试的 30 分钟窗口与特定外部设备绑定，不能推广到所有网络条件。论文对这些缺项的态度是明确承认而非掩盖，例如指出同步稳定性很大程度上来自 Link 协议，网页版功能缩减故未纳入测试。

第 3 个层面是交互与信号处理的取舍。鼠标界面在高分辨率参数控制上受限，未来需要原生开放声音控制与 MIDI 2.0 映射以支持硬件表面；频域变调在低延迟与保真之间只能二选一，默认保即时性；颗粒重合成与频谱冻结等质感功能尚未加入。这些不是技术错误，而是当前原型为保证演出可靠所做的显式裁剪。

要复现这套方法，先做什么才能对上原文条件？

复现应从材料准备开始。按 groove1、groove2 等建立律动文件夹，每个文件夹内放入多轨 wav 或 aiff，并在文件名中同时写入速度、根音与乐器角色。建议先用少量 1 至 16 小节的四轨立体声材料验证解析与路由，再扩展到大文件以观察加载尖峰。加载后检查字典映射是否正确，通道顶部显示的解析根音与移调区间是否与预期一致，角色不明的文件是否被送往辅助总线。

环境与参数要与原文对齐。机器至少达到 M1 加 16 GB 级别，软件用 Max 8，采样率设 44100 Hz，调度间隔设 1 ms。四轨同时回放并开启实时变调，打开两个图形界面电平表以复现满载条件。测量环路延迟时区分输入输出延迟与傅里叶窗延迟，后者在 1024 点窗口下约为 43 ms，属信号路径内部延迟，需确认补偿后跨轨仍对齐。长时间测试可按每 4 小节随机切换场景跑 60 分钟，记录掉音与欠载事件。

同步复现需要 Link 环境。一端跑 MBHD，另一端跑 Ableton Live，第三节点可用运行 Patterning 的平板，观察 30 分钟速度漂移是否小于正负 1 ms，并检查 groove~ 起音是否始终与下拍对齐。用户研究复现若只做功能验证，可用 8 人左右结构与 10 分钟即兴任务，记录可用性量表与 10 分钟内能否独立加载自定义律动，但不要把小样本结果当作跨工具优劣证据。

资源状态需要如实表述。原文给出 Max 补丁与浏览器伴随应用的两个网址，但本次可核对的资源状态只有第三方链接：Roland SP-404MK2 页面当前可用，Karma 页面当前可用，MIDI 组织页面当前可用。Max 补丁与伴随应用的链接不在本次资源状态清单中，因此只能写按原文给出，不写当前可用或已公开。若需引用硬件与协议背景，可用上述 3 个已验证可达的第三方页面作为辅助信息。

何时值得尝试这套路线，还需补哪项验证？

当曲库来源杂、演出需要频繁切换律动、且希望用一个全局调与全局速度兜底时，这套路线值得尝试。它的核心动作很具体：用文件名约定补足速度、根音与角色，用字典做中央查找，用 groove~ 做变速，用 gizmo~ 或 retune~ 做变调，用全局走带加 Link 做内外同步，用静音矩阵做 Dub 式加减法。学习依赖是先理解变速与变调解耦，再理解文件名解析与半音差计算，最后才看界面布局与同步补偿，否则容易把音量表与同步灯当成音质保证。

不值得照搬的场景也要说清。若演出以现场录音叠加、颗粒质感、微分音或复杂和声进行为核心，当前 12 平均律加整数半音量化的做法不够用，需要改造数据结构与和声逻辑。若团队无法接受人工重命名成本，则需先补音乐信息检索管线，用色度特征、瞬态检测与乐器分类自动标注，再谈演出流程。

还需补的验证包括命名缺失时的误判率、不同声卡与缓冲下的延迟分布、大文件并发加载的峰值控制、以及与具体对照系统的同任务比较。论文提出的半自主协演者、马尔可夫链推荐下一律动、颗粒重合成与频谱冻结都属于待验证方向，不能当作已有收益。总体判断是文件名驱动的透明架构降低了多循环即兴的准备与操作摩擦，但可靠结论目前只限于 Max 原型、固定机器条件与小规模用户试用，跨设备与跨人群推广仍需补实验。

📐 原文公式与排版

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

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

⚖️ 评分明细

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

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

← 返回 icmc-2026 论文汇总