Milestones

List view

• 7.0.0

  MIDI 2.0 support: the Universal MIDI Packet format, and the API changes it requires. This is an ABI break — the shared library SO version moves from 7 to 8. Goal: the API changes should not break applications written for RtMidi 6.x — most will need only a recompile. Code that subclasses a backend, or that wraps sendMessage in a void-returning function, will need small edits. Scope and design discussion are tracked in #307. - Add UMP data tx/rx, likely needs new API methods - Add port enumeration that include persistent IDs, subscription like auto-reconnect, support multiple devices of the same product (expose serial numbers), identify device MIDI 1/2 support, and expose function block names and group addressing. - MidiOut::sendMessage should return the number of bytes accepted rather than void, and drain() is added. Getting the sendMessage return value consistent across backends will take some planning given that they all behave differently. - Windows MIDI Services becomes the native UMP transport on Windows rather than a MIDI 1.0 compatibility backend, building on the backend added in 6.1.0. Existing RtMidi applications should be encouraged to switch over from WinMM to WMS as many features will only be available with WMS. UWP unlikely to get any updates as it's essentially being superseded by WMS, but no removal is planned. Users wanting updates to UWP are encouraged to open an issue and submit PRs. - UMP timestamps are 64bit integers, rather than RtMidi's double deltas. This deserves some consideration, and touches on issue #243.

  No due date

  •0/14 issues closed
  0% complete14 open0 closed

• 6.1.0

  Windows MIDI 1.0 correctness, cross-platform send-path fixes, and accumulated housekeeping. No ABI change: code built against 6.0.0 recompiles and relinks unchanged. Adds a Windows MIDI Services backend carrying MIDI 1.0 over UMP, alongside WinMM rather than replacing it. As Windows MIDI Services rolls out, WinMM traffic is routed through it anyway, so a clean, backwards-compatible implementation with a working fallback is what keeps existing applications running — and it gives developers who do not want to take on the API changes in 7.0.0 a supported path forward. Also fixes the WinMM output buffer lifetime and input teardown paths, accepts partial SysEx spans on ALSA, and adds automatic reconnection for ALSA USB devices. Other fixes and housekeeping TBD.

  Due by October 15, 2026

  •36/38 issues closed
  94% complete2 open36 closed