64位Delphi下发送MIDI控制消息的方案或修复求助

• 根因定位：该旧开源包的64位兼容问题全部源于Windows API类型定义不匹配，具体表现为打开输出设备时触发访问违例，和MIDI协议本身的解析逻辑无关
• 逐点修复操作：
  • 替换句柄类型定义：找到单元内所有和MIDI输出设备句柄、设备回调参数相关的LongWord类型定义，全部替换为Windows标准的THandle类型，避免64位环境下64位宽度的句柄被截断为32位值，触发无效内存访问
  • 调整设备枚举逻辑：删除设备枚举缓冲区里硬编码的内存偏移值，全部替换为基于实际类型大小的动态偏移计算，解决64位编译下16字节默认对齐导致的缓冲区错位问题——之前的枚举逻辑拿到的无效设备句柄，就是因为偏移错位取到了缓冲区里的垃圾值
  • 修正短消息发送接口的参数类型：把midiOutShortMsg调用时的3字节消息拼接值的类型从Cardinal替换为ULONG_PTR，匹配64位下Windows API的参数宽度要求
  • 消息值验证：91.17.00格式的MIDI控制消息，拼接为API可识别的长整数值的计算逻辑为$91 + ($17 shl 8) + ($00 shl 16)，修复后直接传入该值即可正常发送，无需额外做通道换算

该包的64位适配层没有对外暴露复杂的内部API，可直接按以下流程完成控制消息发送：

• 单元引用：仅需在uses列表引入NativeMidi单元，不需要额外关联winmm或者其他平台SDK单元
• 基础输出流程：
  • 调用TNativeMidiOutput.EnumerateDevices方法获取系统全量MIDI输出设备列表，方法返回值为设备名称字符串数组
  • 创建输出实例：FOutput := TNativeMidiOutput.Create;
  • 绑定目标输出设备：调用FOutput.Open(目标设备索引)完成设备初始化，该方法内部已经处理了64位下的句柄管理，不会出现旧包的截断问题
• 91.17.00消息发送代码示例：

  // 对应标准3字节MIDI消息：状态位$91（第10通道控制变更）、数据位1 $17、数据位2 $00
  const
    CtrlMessage: array[0..2] of Byte = ($91, $17, $00);
  begin
    // 直接传入三个字节值即可，方法内部自动完成消息拼接
    FOutput.SendShortMessage(CtrlMessage[0], CtrlMessage[1], CtrlMessage[2]);
  end;
  

• 资源释放规则：程序退出前必须先调用FOutput.Close方法断开设备连接，再释放实例，避免64位环境下的系统MIDI句柄残留

常见踩坑提示：两类实现路径都不要混用旧32位包的封装单元，只要类型宽度和Windows系统API不匹配，无论编译为32位还是64位，只要架构对位宽要求不一致就会触发运行时异常。

内容的提问来源于stack exchange，提问作者Dgbaxter