You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. :)
The text was updated successfully, but these errors were encountered:
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.
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:
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. :)
The text was updated successfully, but these errors were encountered: