ESP-Mosaico 黑胶轮滑动画与音乐编排：从设备原型到电脑预览工作台

摘要

我做了一个以黑胶唱片为舞台的轮滑动画项目：人物沿唱片滑行，动作与音乐配合，脚下轨迹和落地特效参与表现。开发过程中，单纯增加动作数量没有解决僵硬的问题，反复烧录也影响了修改效率，于是又增加了电脑端动作编排与预览工具。本文作为系列第一篇，介绍项目目标、当前架构、真实修改流程与排查顺序，并说明电脑端功能和实机版本的区别。动作衔接、音乐卡点与歌词同步将在后续分别展开。

1. 项目背景：会动以后，问题才开始具体

这个项目的起点，是一段把黑胶唱片和轮滑结合起来的动画。我想把类似的小舞台做进 ESP-Mosaico：唱片作为运动空间，人物在上面滑行，声音为表演提供节奏。

最早的需求很容易描述：画唱片、放人物、加音乐。但一旦开始连续播放，问题就变得具体了。小人的脚在动，身体却没有明显换重心；增加转体后，人物像被整体拧过去；配乐换了，动作仍然重复原来的节奏。

这些问题分别涉及动作姿态、运动轨迹、音画同步和观察方法。继续叠加功能之前，我需要一种能停下来检查、回到同一位置比较的开发方式。

2. 设计目标与当前范围

我给这个项目保留了三个主要目标。

第一，人物要完成一段能看懂的表演。普通滑行、蹬步、交叉步、转体和起落，应当有不同的姿态与节奏。风格可以夸张、动漫化，但动作之间需要有连贯关系。

第二，音乐要参与编排。鼓点、音量和节奏速度可以提供不同的信息，帮助安排抬脚、轨迹变化及动作组合。自动分析提供起点，最终仍需要试听和人工调整。

第三，修改结果要方便比较。单个动作演示、拖放编排、暂停定位、工程保存，以及撤销重做，都是为这个目标服务的。

当前电脑端为 1.20.4 ，包含 55 套预制动作。这里的"预制"指程序中已经准备好的动作片段，不能理解成训练出了一个能自动理解所有音乐的动作模型。

3. 整体架构：把编辑、播放和绘制分开

当前电脑工作台的主要关系可以简化为：

text 复制代码

歌曲文件 ──→ 音频解码与分析 ──→ 拍点、能量等编排依据
                                      │
动作库与人工拖放 ──────────────────────┤
                                      ↓
                              工程数据与动作计划
                                      │
音频播放位置 ──────────────────────────┤
                                      ↓
                            C 场景与动作代码 / WASM
                                      ↓
                          场景图像 + 可选歌词叠加
                                      ↓
                                 电脑预览窗口

界面由 Python 工作台组织。studio/app.py 处理操作和预览更新，studio/model.py 管理工程，studio/runtime.py 连接音频播放与画面绘制。

场景和动作部分复用面向设备编写的 C 代码，在电脑端通过 WebAssembly 模块调用。Runtime 是这里的 WebAssembly 执行环境。电脑工具负责把音乐位置、人物与视觉选择交给渲染器，再显示返回的图像。

这样可以在电脑上检查实际场景代码生成的画面，而不是另外画一套只用于展示的网页动画。不过，电脑预览通过，并不等于相同版本已经在设备上验证。

4. 从导入歌曲到保存工程，实际怎样工作

4.1 先分析，再安排动作

导入歌曲后，电脑端进行解码和分析，得到编排可用的时间信息。随后可以逐个点击动作观察，也可以把动作拖到时间轴上的拍点附近，播放检查，再调整位置与衔接。

这个顺序很有用：先确定某个动作在当前音乐里是否合适，再检查它与前后动作的连接。否则，即使单个动作好看，放进整段音乐后也可能显得突兀。

4.2 用音频位置定位画面

主预览读取音频播放位置，再按这个位置计算动作与场景。当前源码中的关键关系是：

python 复制代码

absolute_sample = self.audio.sample
sample = absolute_sample
if self.loop.get():
    sample %= self.project.sample_count

这几行摘自预览更新流程，不是一个完整播放器。它表达的是：播放、拖动和循环时，画面应该找到当前音乐对应的位置。动作库的独立演示另有自己的预览流程。

歌词也是按歌曲位置选择当前一句，再叠加到场景图像上；显示开关只影响字幕是否可见。具体时间边界和异常情况留到歌词同步篇说明。

4.3 保存的是可继续修改的工程

工作台使用 .vskproj 工程文件。它保存动作摆放、编排计划、场景时间点、歌词与预览选择等数据，并引用工程旁的 PCM WAV 音频。加载时会校验音频内容。

因此，工程文件和相邻音频需要一起保留。视频适合展示结果；工程则用于回到同一首歌、同一段动作继续修改。

5. 三次返工带来的实现判断

动作数量与自然感要分别检查。 增加蛇形、交叉步和转体后，有些段落仍然僵。后来检查点从动作名称细化到脚有没有蹬出、重心有没有转移、手臂能否跟上身体，以及落地后是否继续滑走。

放大人物会同时放大问题。 我曾希望通过增大人物看到更多细节，随后发现弯折和停顿也更明显。最后恢复之前的尺寸，把修改重点放在连续姿态上。这次返工让我明确：当时真正需要改善的是流畅程度。

轨迹需要表达接地关系。 小人滑行、抬脚和腾空时，如果脚下始终留着相同的线条，就容易产生漂浮感。项目逐步增加了轨迹粗细、平滑处理，以及落地时的脚边反馈；效果强度也经历过回调，避免特效遮住人物。

6. 当前进度与实现边界

电脑预览里有三位原创动漫人物：青绿双马尾的澄音、银发机能少年凛、粉发的绮星，另保留了参考《无畏契约》霓虹形象的轮滑化二创。

人物、背景、唱片颜色和脚边特效可以分别选择。背景包括雪山、森林、风暴；头发与衣摆跟随滑行、转体和起落摆动。音乐导入、动作编排、工程保存及可隐藏的逐句歌词，都属于当前电脑端范围。

设备方面，前期制作过独立轮滑固件，后来已恢复 Mosaico 0.5.2 应用平台。新的动漫人物、发梢衣摆惯性和 LRC 字幕尚未烧入设备。电脑工作台与硬件固件使用不同版本编号，不能把电脑版本号当成实机功能清单。

目前也不能保证任意歌曲经过自动分析后，都能得到合适的完整表演。不同音乐的重音、停顿与段落差异很大，人工试听和编排仍然有价值。本文没有给出新的实机帧率结论。

7. 遇到效果不对，我会按这五步排查

先确认版本与展示来源。 是电脑预览、导出片段，还是设备旧固件？先核对打开的工程和版本，避免用电脑新增功能去判断设备是否异常。
再核对歌曲与播放位置。 确认工程关联的音频正确，暂停后拖到固定位置，重复试听同一段。歌曲和位置不一致，动作比较就没有可靠依据。
单独演示可疑动作。 观察蹬步、手臂弯折和起落。如果单独演示也不顺，应先调整动作本身；单独正常再回时间轴检查衔接。
暂时减弱视觉干扰。 固定背景、人物和唱片颜色，减少脚边特效，重点看脚是否接地、身体是否停顿、轨迹是否连续，再逐项恢复效果。
保存后重新打开工程。 核对音频、动作位置和预览选择是否一致。若不一致，先区分保存与加载问题，再继续判断动画问题。

这个顺序的目的，是每次只缩小一类问题，避免同时改动作、换音乐、换背景后失去对照。

8. 这个工作台带来的价值

对我而言，电脑工作台最直接的价值是缩短观察和修改的距离。发现落地别扭，可以回到同一个音乐位置再看；某个转体有停顿，可以单独演示；一次修改不合适，也能撤销后比较。

后续回到设备验证时，仍需要单独检查性能、输入和音频等实际条件。电脑工具先帮助我把"动作看起来不对"拆成更具体的问题，再带着明确的修改结果进入硬件阶段。

下一篇会集中讨论 "小人会转圈，为什么看着还是僵"，从蹬步、重心和连续姿态展开。音乐卡点、电脑编排操作、轨迹反馈与 LRC 时间轴会分别成篇。

创意起点来自最初分享的黑胶轮滑动画,本文动图来自本项目电脑端实际渲染，不是实机录像。

我是阿白，感谢你的观看。