本案例把实时演奏、MIDI文件渲染和麦克风音色转换分成三条链。神经网络只预测控制量，波形合成与设备路由在CPU侧完成。

先给出本讲路线图；后续每一段都对应这里的一行，最后回到路线收束。

先让学生建立三种任务模型。实时演奏关注毫秒级反馈，文件渲染关注整曲上下文，DDSP-VST关注实体音频双工链路。

左侧负责源码、固定revision、ONNX检查与前端构建；右侧负责ATC、OM、PyACL、音频和FastAPI。不要把CANN或实体音频操作搬到开发电脑。

重点比较时间模型与上下文。MIDI-DDSP需要完整前后文，不能直接塞入4ms实时按键路径；DDSP-VST只处理单音输入。

上游来源决定迁移方法。把循环状态显式化，并在连续多帧上对齐输出，是两类TFLite模型进入ONNX和OM前的关键。

资源锁不是性能优化，而是正确性条件。多个任务同时打开OM或音频设备会产生无法归因的状态。

先总说明再展示。学生必须把“界面可用”与“模型、音频、时延可用”分开，不能根据截图填写性能或音质结论。后续当前截图是唯一本轮8T证据，历史图不得改变这个边界。

截图来自8T当前运行的服务，系统状态条在截图时隐藏。页面能加载不等于音频设备、Piano OM、MIDI输入或端到端时延已通过；空卷帘只说明当前没有音符事件。

页面主体展示实时卷帘、13/25键选择和触控钢琴。截图不证明按键延迟、音频设备实际出声或Piano OM推理性能。

该模式与触摸屏共享Piano-DDSP会话，但键数和输入来源不同。截图只证明界面状态，不证明实体MIDI端口当前仍连接或音符已被听到。

音频库按MIDI源组织多个渲染版本，卷帘与播放目标必须同步切换。截图不证明WAV已完成、可播放或音质合格。

页面展示声部分离、乐器分配和文件卷帘。渲染任务完成图不等于模型数值一致性或输出音频已在实体设备验收。

页面展示音高、响度和音色控制区域。截图中实体输入未形成可听内容，不能证明Feature/Control OM、麦克风或音箱路径已验收。

输入门负责底噪校准、开启阈值、迟滞、保持与开闭时间。截图只证明控件和默认状态，不代表麦克风采到真实声音或安全静音已实测。

实时卷帘服务于现场反馈，文件卷帘服务于整曲定位。引擎和状态必须分开，否则刷新或回放会造成错误轨迹。

设备路径必须显式。尤其PulseAudio monitor只是回放监视，不是麦克风；自动改路会破坏实验归因。

状态快照与事件流配合使用。断线恢复先读快照，再接续事件；浏览器永远不提交任意文件路径或设备命令。

四个证据层不能互相替代。尤其HTTP 200或页面动画不能证明OM推理和实体音频输出。

本轮截图隐藏系统状态条；历史图使用物理裁切/脱敏派生文件，原图不再直链。两类截图都没有真实音频内容；发布新增截图时仍要重新核对设备和隐私字段。

收尾再次强调“既有UI截图”标签。任何模型、音频或时延结论都需要本轮设备、命令、原始日志和对应验收协议。