OSC 数字看着一样却收不到，怎样用 ,i 与 ,f 核对参数类型

OSC中整数1与浮点数1.0不是同一种参数。类型标签必须与实际字节编码一致，接收方法若只接受float，收到合法int也可能拒绝调用。先逐字段对齐地址、标签与参数，再查网络，比只看监视器上显示的“1”更有用。

先固定输入与适用条件

本题用自定义/cue/level地址，分别发送类型为,i和,f的同一数值；只做离线编码，不向设备发送消息。OSC 1.0的整数与浮点都为四字节大端，但含义不同；参数顺序也是接口契约的一部分。地址相同不能证明参数兼容，字符串“1”又是第三种不同输入。

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

按字段与边界执行

1. 先写出接收方法的参数契约，例如只接受一个float32且取值在零到一之间。这个值域是项目约定，不是OSC为所有地址规定的标准范围。

2. 保留完整报文hex，检查类型标签是否逗号开头，以及标签后参数总字节是否足够。不要把监视软件显示值作为原始编码证据。

3. 分别用大端整数和浮点解码四个参数字节，对照预期1与1.0。交换类型标签但不改字节，作为错误输入验证接收端是否明确报错。

4. 应用若允许int转float，应在桥接配置中显式记录转换与越界规则。不能为了“能触发”而忽略未知类型，也不能默认所有接收软件都会自动强制转换。

用具体样例核对结果

整数1的参数是00 00 00 01，浮点1.0是3F 80 00 00。附件生成两个完整OSC包，结果同时保存参数hex和按声明类型的解码值。若把整数的四个字节按float解释，得到一个极小数而不是1.0；这是结构解释错误，网络可达并不能修复。

通过条件是标签、参数数量与二进制含义一致，且接收方法接受该类型和值域。四字节长度正确只能证明没有截断，不能证明类型正确。若接收应用仍无反应，再核对方法是否注册、地址是否精确匹配以及返回日志。不要把本例自定义/cue/level当成任何产品默认存在的控制命令。

下载与复现

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

input保存地址和数值，analyze生成两个包并实际解码对照。交给对接双方时，明确写“一个float32”比写“一个数字”更可靠；若有桥接转换，保留转换前后的报文。

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

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

对接下一步与一级来源

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

• OSC 1.0 i/f类型标签与大端原子类型。

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