MIDI 两块控制器同键串场，怎样检查状态字节里的通道号

同一个note在两块控制器上串场时，核对路由键是否包含MIDI通道。状态字节低四位编码零到十五，对应界面通道一到十六；把低四位直接显示为通道号，或者全局忽略通道，都可能让配置对不上。

先固定输入与适用条件

附件只处理三个完整Note On包，分别来自通道1、2、16，note都为60。端口身份仍独立于通道：两个设备也可能都发通道1，不能指望通道在所有硬件间天然唯一。这里的Omni只是应用是否接受全部通道的示例策略，不向设备发送通道模式命令。

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

按字段与边界执行

1. 先记录输入端口及原始状态字节，再将高四位消息类型与低四位通道拆开。不要只在日志中保留“Note 60”，那会丢失路由证据。

2. 把低四位加一形成界面通道号。0x90、0x91、0x9F对应通道1、2、16，特别用最后一个边界值检查是否错误限制成十五路。

3. 建立端口、通道、note到动作的明确映射。本例将三个键指向三个虚拟展区，未配置键输出未匹配而不是默认落入第一个展区。

4. 分别演练指定通道过滤与接受全部通道的策略，比较命中集合。现场若出现串场，再查端口合并、通道重写或设备默认通道，而不是先换音符编号。

用具体样例核对结果

三条样本90 3C 64、91 3C 64、9F 3C 64的note与力度完全相同，只有状态低四位不同。离线报告分别输出channel=1、2、16及对应虚拟动作；过滤通道2时只保留第二条，接受全部时保留三条。脚本断言没有把0x9F误解释为通道15。

通过条件是通道往返编码一致、每条实际来源路由可追溯、未知键不会意外触发。若两块控制器都被操作系统合并到同一个端口且同通道同note，接收方仅凭这三个字节无法区分物理设备；需要上游重新分配或保留端口来源。不要在无法区分时声称增加一个软件标签就恢复了身份。

下载与复现

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

input与result保存原始状态及两类过滤结果。交接清单至少保留端口、界面通道、线上低四位和note，四者同时明确，才能避免下一位开发者再次出现一基零基偏移。

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

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

对接下一步与一级来源

基础背景可看MIDI 控制协议在展厅的应用速查。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• 通道编码0-15对应显示1-16。

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