MIDI Clock 有节拍却没有影片位置，怎样与 MTC 分开做桥接

MIDI Clock提供节拍脉冲，MTC提供时分秒帧，两者不能互相替代。只有Clock时可以估算节奏，却不能知道影片已经播放到哪一秒；若桥接需要绝对定位，还需明确MTC、外部定位或项目自己的时间原点。

先固定输入与适用条件

本例将速度固定为120 BPM，每四分音符24个Clock，生成一组理想脉冲时间；同时列出Song Position Pointer值8。MIDI中的SPP单位是六个Clock，与口语“一拍”不一定相同。Start、Continue、Stop是传输控制事件，不能单凭它们推断影片帧号。

本篇的OSC内容限定1.0规范，MIDI内容限定1.0字节消息；未涉及MIDI 2.0的UMP编码。桥接动作属于接收应用约定，不能从协议格式推断产品已经支持。

按字段与边界执行

1. 先写清桥接目标是跟拍、启停还是绝对定位。把输入能力列为Clock、SPP、MTC及显式定位，缺少的项标记未知，避免承诺超出输入信息的行为。

2. 在固定速度模型中，用每分钟六十秒除BPM再除24得到Clock间隔。实际输入若有抖动，应保留原始间隔，不能用理想值覆盖观测。

3. 把SPP转换为Clock计数时乘六，再按四分音符24个Clock计算歌曲拍位。这个位置属于歌曲时间结构，不天然对应某一条影片时间线。

4. 约定Start重置到哪里、Continue从哪里继续、Stop是否保持位置，且与MTC定位流程分开。应用日志应同时记录传输状态和位置来源。

用具体样例核对结果

120 BPM下四分音符500毫秒，Clock间隔为125/6毫秒，即约20.833333毫秒。附件生成25个时间点覆盖24个间隔；SPP=8等于48个Clock，也就是两个四分音符，在固定速度模型中相当于1000毫秒。脚本明确把影片绝对位置留空，因为没有提供影片原点或时间码。

通过条件是单位换算明确、脉冲数量与间隔数量不混淆、没有凭Clock补造影片位置。速度变化后不能继续拿固定BPM乘全部历史Clock数，必须积分实际节奏或使用明确的位置输入。真实软件也可能忽略SPP，因此接口宣称“支持MIDI”不足以证明支持所有定位消息，需要逐项确认。

下载与复现

analyze.py、input.json、result.json。

input记录BPM、每四分音符脉冲数及SPP，result保存精确分数时间和桥接能力边界。把这份契约交给播放与控制双方确认后，再使用实际消息验证；本例没有任何同步精度或现场跟拍效果数据。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看多轨时间线编排 + LTC/MTC 时码同步原理。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• F8为24次每四分音符；SPP一拍为六Clock。
• MTC为时码类消息。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。