Proposal: Rearchitecting QMidi for MIDI 2.0 and Extendibility

[CodeforEvolution]

The Problem

Hello! I'm currently working on the macOS backend and trying to fix issues reported by users. Notably however, I notice that the current design of the library is inflexible (C++ inheritance is not used as an example), and I believe the idea of QMidiOut and QMidiIn only being able to connect to one input or output leaves out certain use cases for the library, especially without a coordinating "roster-like" class.

Additionally, with the release of the MIDI 2.0, I believe the library needs to be adapted to interact with these new specifications.

The Possible Solution

I would like to try to redesign the library in a "Factory Method" way:

• QMIDIRoster: A class that handles system wide midi notifications, device enumeration, and the creation/destruction of the client's midi inputs and outputs. In other words, as defined by the MIDI 2.0 Specification, this represents a MIDI Gateway.
  • Can register and unregister the client to receive midi notifications such as new devices, status changes, and more.
    • Received as Qt signals
  • Creates QMidiInput and QMidiOutput objects for the local application that represents inputs and outputs that can be viewed by other MIDI handling applications.
  • Represents other MIDI speaking applications, software, and hardware as a QMIDIDevice.
• QMIDIDevice: Class that represents a single remote software/hardware-based MIDI device and its collection of QMIDIEndpoints.
• QMIDIEndpoint: Abstract base class that a represents a source/destination for handling incoming/outgoing Universal MIDI Packets (UMPs).
  • QMIDIInput: Represents a single input/source for incoming midi events.
  • QMIDIOutput: Represents a single output/sink/producer for outgoing midi messages/events.
• QMIDIPacket: Represents a single Universal MIDI Packet (UMP).
• QMIDIPerformance: A list of QMIDIPackets and extra metadata that represents a complete MIDI piece.
  • QMIDIImporter: Abstract base class for importing in different MIDI file formats such as Standard MIDI Files (SMF).
  • QMIDIExporter: Abstract base class for exporting to different MIDI file formats, such as SMF.

So...What now?

This is only a proposal, so please, leaves comments and suggestions here. Furthermore, tell me I'm wrong and say a re-architecture is not necessary if you believe so. :)

[waddlesplash]

I'm not so sure about QMIDIPerformance. Otherwise this looks like a good proposal.

To be honest, I don't do much with MIDI these days, so I haven't looked into the code in this library in years...

[St0fF-NPL-ToM]

The proposal is great and I'd take the windows version of it. But so far it seems M$ only has announced UWP Midi 2.0 Support, but it's not released, yet. Also I think there should be communication to Qt, if it wouldn't make sense to include QMidi in Qt as a standard module, and how it should be designed for this.