英文题目：OrbitScore: A Domain-Specific Language for Polymetric Live Coding Based on Multilayered Temporal Structures
会议身份：
conference:icmc:2026:conference-paper-id:paper-721
✅ 来源为官方会议 PDF；表格与 Figure 按原文证据绑定。PDF 公式以原页区域图片展示，未冒称作者原始 TeX。
标签：#软件工具 #信号处理 #实时处理 #音乐 #音乐生成
评分：6.8/10 | 创新 1.2/2 | 技术严谨 1.0/1.5 | 实验充分 0.5/1.5 | 清晰度 0.8/1 | 影响力 0.8/1.5 | 开源 1.2/1.5 | 可复现 0.3/0.5 | 工程/实践 1.0/1.5
排名：前50% | 文档类型：系统技术报告
👥 作者与机构
- Hiroshi Yamato：机构信息未能从会议 PDF 纯文本可靠映射
📌 核心摘要
OrbitScore面向现场编程中的多节拍表达，输入为文本代码与全局速度、输出为经SuperCollider合成的多层音频，难点是各序列保持独立节拍又在可计算边界周期性对齐，而传统工作站与统一时钟语言难以原生表达该结构。方法链分三步：解析器先将beat(n by m)与play嵌套语法转为抽象语法树，解释器承接该树维护序列状态并在参数变化时触发重算。计时引擎按节拍参数生成带起始时间的单小节TimedEvent计划，经开放声音控制协议预发送给音频引擎驱动SuperCollider播放，VS Code插件提供高亮与即时执行以闭环修改。与TidalCycles共用脉冲的拼贴不同，该系统让每层以独立有效速度运行并在最小公倍数边界自然重合，保留可变节拍记谱的独立性。在BaseBPM为120 BPM的设置下，4:(3/4)层的速度指标为160 BPM，高于4:(4/4)层的速度指标120 BPM。结论适用边界受限于macOS单机采样回放验证，合奏跟随与长期漂移等外推尚未验证。在48kHz与256采样缓冲硬件条件下音频延迟约为5ms，该延迟即主要部署代价。
🔗 开源与复现资源
- 代码相关资源：https://github.com/signalcompose/orbitscore — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么：为什么统一速度网格不够用？
本文的输入是论文原文与 3 张官方原图像素，目标是让刚进入音频领域的研究生能核对并复述 OrbitScore 的方法、条件与边界。必须保留的信息包括理论记法、拍号语法、同步计算、系统链路、演出配置与局限，输出是 1 篇按学习依赖展开的中文解读。
先把任务说清楚。常规数字音频工作站与 MIDI 系统默认整首曲子共用一个速度与网格，量化、剪辑、对齐都围绕这个网格做。2000 年以后流行、爵士与嘻哈里越来越多声部各走各的拍子，例如 4 拍一小节的层与 5 拍一小节的层同时进行，各自速度不同但每隔一段时间在第一拍相遇。白话说就是多条时间流：每条有自己的拍速与小节感，整体又有周期性汇合点。英文叫 Multilayered Temporal Structures，后文简称多层时间结构。
这不是把声音丢给模型做分类或生成的问题，也不是训练神经网络的问题。论文要解决的是表达与执行问题：如何在现场编程中写出各自独立又能自动对齐的多节拍结构，并以足够低的延迟发声。理解这一点很关键，否则会误把 OrbitScore 当成自动作曲模型或效果器。它的样本是一段代码加一组声部配置，输出是按时发出的声音事件，评价方式是现场能否构造、修改并保持同步，而不是准确率曲线。
相关路线做了什么：非洲复节奏、极简派与现场编程语言有何不同？
论文把相关工作分成 3 条线，比较维度是同输入、同目标、同运行阶段，而不是把风格差异当成胜负。第一条线是非洲复节奏及其传播。西非 12 拍循环被视为复节奏原型，4 拍脉冲与 3 拍脉冲同时发音形成纵向黑米奥拉，几何分析指出 tresillo 这类 3 加 3 加 2 时间线具有适合制造复杂性的数学性质，之后经拉丁音乐、节奏布鲁斯、爵士与摇滚延续。印度塔拉与古巴克拉维也被用来说明多重时间划分并存。论文在此区分交叉节奏与真正复节奏：前者是一个周期内按整数比划分，后者包含非整数比划分与摇摆或重音带来的微观时值变化。
第二条线是美国极简主义相位技术。史蒂夫·莱克的渐进相位移动是在统一时间框架内通过位移制造复杂性，而多层时间结构是真正独立的速度流周期性对齐，这是论文强调的根本差异。第 3 条线是现场编程语言与多速度作曲工具。TidalCycles 用 Haskell 内嵌语言与迷你记法做模式变换，可用花括号写不同长度模式共享脉冲的多节拍；Sonic Pi 强调时间语义与可学性，但各序列共享全局时间参考。
Polytempo Composer 计算不同速度进程的重合点，但面向作曲与记谱而非实时交互。论文指出的研究缺口是 4 条同时成立的要求：每序列独立拍号、在计算出的小节边界自动同步、可在演出中实时修改、音频延迟足够低。已有系统没有同时覆盖这 4 条，这就是 OrbitScore 的定位。
要解决的具体问题是什么：每层独立拍号如何自动重合？
把问题收敛成一个可操作的例子。假设全局参考速度是 120 拍每分，A 层是常规 4 拍一小节，B 层是把 5 拍压缩进同样参考时长的 4 比 5 比 4 层。两层起点相同但行进速率不同，B 层完成一小节只需 A 层时间的百分之 80。问题是：写代码的人只写各自拍号，系统要自动保证它们在正确时刻相遇，且演出中改拍号后新的相遇点依然正确。
论文用两层与 3 层实例把问题量化。两层例子是 4 拍层与 5 拍层，最小公倍数是 20，4 拍层走 5 小节，5 拍层走 4 小节，在第 21 拍同步。3 层例子是 3 拍、4 拍、5 拍，最小公倍数是 60，分别走 20 小节、15 小节、12 小节，在第 61 拍同步。在基准速度 120 下 3 层有效速度分别是 160、120 与 96 拍每分。两层之间部分重合还会形成特征性动机。这组数字同时说明任务的两个难度：速度换算必须按拍数反比给出，同步点必须按最小公倍数给出，任何把长模式套进同一脉冲的做法都不能替代真正不同的有效速度。
方法全景：从一行拍号到声音经过了哪些环节？
沿一个样本走完全程有助于建立全景。假设表演者写下全局速度 120，新建 kick 序列并写 kick.beat(4 by 4)，新建 perc 序列并写 perc.beat(5 by 4)，分别绑定鼓声采样并写入播放模式，然后让两者循环。输入是文本代码，表示是全局上下文加多个序列对象，组件是解析、解释、计时与音频 4 段，目标是各自按独立拍速发声并在最小公倍数边界对齐，输出是经开放声音控制协议发给 SuperCollider 的声音触发。
这里先解释术语。可变拍记谱是白话的各走各的小节线：每层按自己的拍数显示与推进，不强行对齐成一份总谱；固定拍记谱则是为了合奏阅读把所有层压进主拍号。OrbitScore 在内部采用可变拍做法，每序列维护自己的时间参考，调度器负责自动同步。
多层时间结构 × beat(n by m)： 多层时间结构负责定义音乐要什么：多条不同速度的线同时走并在计算出的小节边界对齐；beat(n by m) 负责给出怎么写：把理论记法 4:(n/4) 逐字变成可执行语句，搭配理由是两者共享同一个 n，组合后表演者改一个数字就改了一条时间流的速度与对齐周期。
下图是理解速度关系的关键，它把同一参考时长切成不同拍数，是后文所有换算的直观基础。在阅读时不要把它当成装饰，要把它当成拍数越多单拍越短的证据。
看图路径： 1. 先看三行共用同一左右虚线参考时长，确认是同一段时间被切成不同拍数；2. 再对比第一行 4 格、第二行 5 格、第三行 3 格的格宽，确认拍数越多单拍越短；3. 最后核对右侧 120 BPM、96 BPM、160 BPM 标注，确认拍数与有效速度成反比
论文图 2。原论文 Figure 2：“Comparison of n-beat notation showing how different beat counts map onto the same reference duration. At BaseBPM = 120, the effective tempos are 120, 96, and 160 BPM respectively.”。
这张图显示三行共用同一左右边界，第一行 4 格对应 120 拍每分，第二行 5 格对应 96 拍每分，第三行 3 格对应 160 拍每分。格宽直接反映单拍时长，拍数与有效速度成反比。它支持的判断是：不同拍数映射到同一参考时长时，系统必须给出不同的有效速度，而不是让长模式在同一速度下跨小节回绕。未验证的推测是听感上的紧张与解决，论文只报告结构重合，不承诺特定情绪效果。
为核对速度换算，先提出比较问题：在同一基准速度下，不同拍数层的有效速度是否按反比给出，方向是否拍数越多速度越慢。下表整理了论文在基准速度 120 下报告的 3 组对应关系，单位保留原文拍每分写法。
| 层记法 | 拍数 n | 参考时长 | 有效速度 | 结构含义 |
|---|---|---|---|---|
| 4:(4/4) | 4 | 同一参考时长 | 120 BPM | 参考层 |
| 4:(5/4) | 5 | 同一参考时长 | 96 BPM | 压缩进参考时长 |
| 4:(3/4) | 3 | 同一参考时长 | 160 BPM | 扩展至参考时长 |
上表的主要收益是换算规则可复述：有效速度等于 4 乘基准速度除以拍数，拍数变大速度变慢。代价是这只是单小节内的静态对应，没有包含最小公倍数周期与演出中改拍号后的动态重算，需要后文同步表补足。TidalCycles 花括号长模式在同一脉冲下回绕的做法在此不算同一条件，不能直接比较快慢。
同步如何计算：最小公倍数与拍速换算怎么做？
本节承担把数学讲成可执行步骤的任务。论文给出同步拍等于各层拍数的最小公倍数加 1，每层到同步前的小节数等于最小公倍数除以该层拍数，每拍相对长度与有效速度分别按最小公倍数周期与基准速度换算。符号含义是 n1 到 nk 为各层拍数，BaseBPM 为参考层速度，BPMi 为第 i 层的有效速度。计算目标是回答两件事：何时重合，每层在重合前走了多少小节。原文明确的实现不是在演出前算出一个总谱，而是让每层独立循环，靠周期自然重合。
可变拍记谱 × 独立循环调度： 可变拍记谱负责观念分工：每层保留自己的小节线，不强行压进统一总谱；独立循环调度负责计算分工：每层按自己的小节时长独立循环，靠主机时钟自然在最小公倍数处重合，搭配理由是都不去预先算一个全局网格，组合后同步点从结构中长出来而不是被量化对齐。
下图是两层同步的最小实例，阅读时应先确认小节数差异，再确认时间轴刻度，最后确认重合点。它把公式里的 20 与 21 变成了可见的块数与轴点。
看图路径： 1. 先看上行 5 拍层标为 M1 到 M4、下行 4 拍层标为 M1 到 M5，确认小节数不同；2. 再看底部 Beat 轴从 1 经 5、10、15 到 20/21，确认 20 拍周期后在 21 拍对齐；3. 最后核对左右虚线同时切过两行起点与终点，确认对齐是周期性重合
论文图 1。原论文 Figure 1：“LCM-based synchronization of 4-beat and 5-beat layers. The 4-beat layer completes 5 measures while the 5-beat layer completes 4 measures, both converging on beat 21.”。
这张图上行是 5 拍层共 4 个小节，下行是 4 拍层共 5 个小节，底部 Beat 轴标出 1、5、10、15 到 20 与 21，左右虚线同时切过两行起点与终点。可见内容支持的判断是：4 拍层走 5 小节、5 拍层走 4 小节后在第 21 拍汇合，最小公倍数 20 是周期长度。像素不能精确辨别每拍内部细分的数值，因此不硬写拍内时刻，只报告小节数与同步拍。
为核对同步条件，提出比较问题：在给定拍数组合下，各层小节数与同步拍是否满足最小公倍数关系，条件是否一致。下表整理论文报告的两组实例，拍数、最小公倍数与同步拍保留原文整数写法。
| 组合 | 各层拍数 | 最小公倍数 | 各层小节数 | 同步拍 |
|---|---|---|---|---|
| 两层 | 4, 5 | 20 | 5, 4 | 21 |
| 3 层 | 3, 4, 5 | 60 | 20, 15, 12 | 61 |
| 速度对照 | 3, 4, 5 | 60 | 20, 15, 12 | 160, 120, 96 BPM |
| 含义 | 独立拍号 | 周期长度 | 周期内小节数 | 重合点 |
| 边界 | 整数拍 | 可计算 | 整除 | 周期加 1 |
上表显示两层与 3 层实例都满足小节数等于最小公倍数除以拍数，同步拍等于最小公倍数加 1。代价是无理数或无限小数比例会随时间累积漂移，论文明确指出这是单进程时钟精度与多层结构本身难度的共同限制。未评测的边界是非整数拍与极长演出的漂移量，原文没有给出测量数字，因此只能说可能随时间扩大，待验证。
代码与声音链路：解析、计时与 SuperCollider 如何分工？
本节讲系统实现，要求能复述每个组件的输入输出。OrbitScore 是基于 TypeScript 的内嵌领域专用语言，提供全局上下文、序列与传输 3 类构造。解析器把 beat(n by m) 与嵌套播放结构解析成抽象语法树，解释器维护序列状态并在参数变化时触发计时重算，计时引擎按拍参数生成带精确起始时刻的定时事件，音频引擎经 supercolliderjs 库用开放声音控制协议与 SuperCollider 的合成服务器通信，编辑器扩展提供语法高亮与快捷执行。架构是响应式：参数变化经计时引擎重算时刻表并更新音频引擎，不中断播放。
层级播放结构 × 定时事件： 层级播放结构负责表达拍内细分：play(1,(2,3),4) 这类嵌套元组把一个拍位再切成两个事件；定时事件负责把细分变成可调度的事实：每个事件带切片号、起始时间、时长和嵌套深度，搭配理由是前者是人的写法、后者是机器的时刻表，组合后 tresillo 与连音能在多节拍框架内被精确定位。
下图是系统链路的总览，阅读时应沿箭头走主路径，再确认声音出口在哪里。它决定了复现时哪一段出问题该查哪里。
看图路径： 1. 先沿 VS Code 扩展指向解析器的箭头看输入入口；2. 再沿解析器到解释器到计时引擎到音频引擎的主链看处理顺序；3. 最后看音频引擎经 OSC 指向 SuperCollider 的斜箭头，确认声音在外部合成
论文图 3。原论文 Figure 3：“OrbitScore system architecture. DSL components process code and schedule events, communicating with SuperCollider via OSC.”。
这张图可见从左下编辑器扩展指入解析器，再依次指向解释器、计时引擎、音频引擎，最后由音频引擎经 OSC 斜箭头指向 SuperCollider 合成服务器。虚线框住语言侧 4 段，声音侧在框外。支持的判断是：语言处理与声音合成解耦，延迟主要取决于 SuperCollider 音频硬件配置。原文报告 256 采样缓冲在 48 千赫下约 5 毫秒延迟，适合现场。不能从该图猜出具体合成器参数或网络拓扑，像素只显示模块与方向。
音频能力按原文交代：支持常见音频文件播放与动态缓冲管理，可实时调制音高、幅度与声像，输出为 48 千赫 24 位。开放声音控制消息分出站合成触发与缓冲命令、入站服务器状态与缓冲完成通知，消息带时间戳以利用服务器内部调度精度，调度器会预发送以抵消网络延迟。局限是当前只做采样回放，没有超出 SuperCollider 能力的内置合成，这是后文复现必须注意的依赖。
有没有训练：本研究未训练什么，真实计算是什么？
本研究没有训练阶段，没有神经网络权重更新，没有梯度路径、损失函数、优化器、冻结与解冻、训练集划分与早停。这是语言与系统论文，不是模型训练论文，必须明确说明，以免误把演出当成测试集准确率。
真实计算是 3 类确定性构造与运行时计算。第一类是解析与解释：把文本变成抽象语法树并维护序列状态，参数变化触发重算。第二类是计时计算：按拍数做最小公倍数同步与拍速换算，生成一小节循环的定时事件表，事件含绝对起始毫秒、时长、切片号与深度。第 3 类是音频调度：经开放声音控制协议预发送带时间戳的消息，由 SuperCollider 按内部时钟发声。
开发过程采用测试驱动做法，单元测试覆盖事件计时与语法树生成，集成测试覆盖协议通信、缓冲管理与传输协调，音频输出的时值准确性需人耳验证，自动化测试难以覆盖。开发借助大语言模型生成代码、调试与文档，领域专用语言先行的做法被报告为有效协作基础，初始可演出版本约三周完成。不能把无训练等同于输出完全确定，漂移、缓冲与人工操作都会引入不确定性。
演出与开发条件：用什么设备、在哪里、代码是否可得？
实验条件按原文交代，分为公开演出与开发度量两部分。演出是 Scratch 与 Build 活动 2025 年 10 月 6 日在东京节点实验室的东京首场，同场有伦敦与苏黎世现场编程社群嘉宾。演出时长 50 分钟，配置是 M1 芯片笔记本在编辑器中运行 OrbitScore，SuperCollider 音频服务器用 256 采样缓冲，外部音频接口 48 千赫 24 位，屏幕向观众投影代码。代码资源状态是可用，地址为信号作曲组织的开源仓库，论文给出约 7000 行 TypeScript、不含测试与配置，提交历史跨 6 个月迭代，核心计时引擎有单元测试覆盖。按资源规则可写当前已公开可用。演出视频有在线链接，但本次解读只依据论文文字与原图像素，不转述视频中的听感。
演示的能力按原文列出：同时运行 4 比 4 比 4、4 比 5 比 4、4 比 7 比 4 序列并自动同步，播放中修改拍号后重算同步点，嵌套播放结构做出 tresillo 等复杂细分，增量加层与静音构建与解构织体。观众可见代码变化与即时声音结果，这是现场编程透明性的要求。必须保留的关键超参数是基准速度、拍号、缓冲大小与采样率，缺项是房间声学、观众噪声、具体采样内容与音量，这些未报告因此不纳入可比条件。
主结果是什么：与 TidalCycles 的同任务写法有何差异？
主结果是定性系统验证而非定量打榜，测的是能否在真实演出中构造并修改多层节拍，比较对象是实际可运行的 TidalCycles 写法，条件是同一音乐意图即 4 拍层加 5 拍层。OrbitScore 写法是两行各自声明拍号并给出播放模式，TidalCycles 写法是用花括号把不同长度模式放在同一脉冲下。论文报告的差异是：前者每层有效速度真正不同，5 拍层以基准速度的百分之 80 运行，各自小节结构在最小公倍数边界重合；后者长模式在同一速度下跨周期回绕。原文明确说这种直接性降低现场认知负荷，因为模式直接映射理论记法而无需中间换算。
传输控制 × 同步保持： 传输控制负责演出动作：RUN 1 次触发、LOOP 持续循环、MUTE 静音但保留时间上下文；同步保持负责不变量：静音与改拍号时不中断各层的循环相位，搭配理由是现场需要增减声部而不推倒重来，组合后加层、减层、换拍号都可以在最小公倍数结构不断裂的前提下完成。
这里区分直接报告与有限解释。直接报告的是语法可写、演出可跑、同步可保持；有限解释是认知负荷更低与织体构建更顺手，这有演出过程支持但没有对照实验与量表；未验证推测是更广泛采用后能推进节奏认知，论文只作为展望。反证是系统不能听外部声音，不能与人类乐手的微观时值对话，这限制了合奏结论。总体趋势不等于每一步都成立，改拍号瞬间与极端拍数组合的稳定性没有逐拍测量。
拿掉哪一块会怎样：论文做了哪些对照与失败条件？
论文没有神经网络消融表，但按证据展开了 3 类特有对照，可视为功能层面的反证。第一类是记谱对照：可变拍在内部保留各层独立小节线，固定拍为合奏阅读压成主拍号但遮蔽多节拍结构，OrbitScore 选前者，代价是习惯总谱的乐手阅读成本更高。第二类是调度对照：显式算最小公倍数同步点 versus 每层独立循环自然重合，论文实现选后者，2000 毫秒与 2500 毫秒循环每 10000 毫秒对齐，代价是非终止小数长期累积漂移。第 3 类是声音对照：采样回放加实时参数调制 versus 内置合成，论文选前者依赖 SuperCollider，代价是平台受限与音色设计受外部工具约束。
未胜出项也要说明。TidalCycles 在模式变换算子与同一脉冲多节拍方面更成熟，Sonic Pi 在教育可及性与时间语义方面更完整，Polytempo Composer 在速度进程计算方面更专注，OrbitScore 只在同时满足独立拍号、自动同步、实时修改与低延迟这一窄条件下有专门支持。未评测边界包括多机时钟、网络抖动、外部 MIDI 同步，这些在原文未来工作中才提到，不能当成已验证能力。
边界在哪里：平台、学习与听觉缺了什么？
论文明确列出 4 条局限。平台仅支持 macOS，因 SuperCollider 集成依赖所致，跨 Linux 与 Windows 是未来工作。学习曲线要求同时熟悉编程概念与多节拍理论，教育材料尚未开发。合成限于采样回放，没有超出 SuperCollider 能力的内置合成。最关键的是无聆听：系统不能响应外部音频输入或其他表演者的时值，是严格调度器，无法根据听到的内容做微观时值调整，而人类合奏恰靠这种时间对话形成律动。
这意味着 ensemble 结论必须收敛：单人多层现场可成立，与人同台的时间对话尚未解决。缺失证据不是技术错误，相关性不是因果，没有测量误判率、端到端延迟分布与长时间漂移曲线，就不承诺这些量得到改善。训练资源、推理开销、输出帧率与实际延迟要分开讨论，本文只有缓冲与采样率给出的约 5 毫秒音频延迟，没有端到端从改代码到出声的延迟测量。
复现先做什么：从仓库到出声的最小步骤是什么？
何时值得尝试：如果作品需要多条真正不同速度的层周期性相遇，且表演者愿意用代码改拍号，就值得试；如果只是同一速度下不同长度循环错位，用已有现场编程语言的花括号或模式变换已够，不必引入新系统。复现先做 4 步。第一步取公开仓库核对版本与约 7000 行规模，确认运行环境为 macOS 并装好 SuperCollider 合成服务器。第二步按论文链路启动语言侧与声音侧，确认开放声音控制双向连通与缓冲分配正常。
第三步用最小两层复现同步：全局 120、新建 4 拍与 5 拍序列、分别循环，核对是否在 20 拍周期后于第 21 拍重合，有效速度是否为 120 与 96 拍每分。第 4 步再试 3 层 3、4、5 与演出中把 5 拍改 7 拍，观察重算是否不断裂。
还需补的验证是论文未给出的部分：长时间运行的漂移量、改拍号瞬间的过渡行为、不同音频接口下的实际延迟分布、人耳对同步精度的评价协议。这些补上才能把可用变成可靠。区分代码开源与系统可运行：仓库公开不等于开箱即响，SuperCollider 版本、采样文件路径与音频硬件都会影响结果，复现报告应写清这三项。
收束：这篇论文留下了什么可复述的方法？
收束成可复述的三句话。方法上，用 beat(n by m) 把 4 比 n 比 4 理论变成可执行语句，每序列独立循环并共享全局传输，靠最小公倍数自然重合，经开放声音控制协议由 SuperCollider 发声。证据上，基准 120 下 4 拍、5 拍、3 拍对应 120、96、160 拍每分，4 拍加 5 拍在 20 拍周期后于第 21 拍同步，50 分钟公开演出展示了加层、静音与演出中改拍号。边界上，仅 macOS、只做采样回放、不能听外部声音自适应，非终止小数长期可能漂移。
对初学者的常见误解要纠正：拍数多不等于速度快，在同一参考时长下拍数越多单拍越短、有效速度越慢；同步不是量化到全局网格，而是各自循环在最小公倍数处相遇；无训练不等于完全确定，时钟、缓冲与人工操作仍带来不确定性。记住这三点，就能在不夸大效果的前提下复述全文方法与条件。
📐 原文公式与排版
以下展示论文原页中的数学表达区域，保留原始上下标、分式和符号排版。区域序号仅用于本文导航，不是论文公式编号。
区域 1 · 查看论文原页
区域 2 · 查看论文原页
另有 20 个候选区域因边界不明确或图片数量、尺寸限制未展开；请查看完整论文中的原始排版。
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
- 评分规则：type-aware-v1
- 评分模型：muse-spark-1.3-contributor
- 评分请求协议：openai_responses