A really thin Swift layer on top of Core MIDI that opens a virtual MIDI destination and port and connects to any MIDI endpoints that appear on the network, no questions asked.

Currently just supports some MIDI v1 messages. However, it also provides enhancements to MIDIPacket and MIDIPacketList to support building new ones and to parse them.

This package basically sets up MIDI and connects to all available inputs it finds. Connection state can be monitored by installing a Monitor instance, and actual MIDI commands can be observed by installing a Receiver instance. Everything else should be handled automatically by the package.

Create a new MIDI instance passing in a name to use for the endpoints that it will create, and a unique ID that will be assigned to the endpoints:

let midi = MIDI(clientName: "Na-Nu Na-Nu", uniqueId: 12_345,  midiProto: .legacy)
midi.monitor = my_monitor
midi.receiver = my_receiver
midi.start()

Ideally, this uniqueId value will actually be unique to your MIDI network. However, there is no way to guarantee that so instead one should install a Monitor to observe the unique ID value that is passed to Monitor.initialized routine once initialization is complete. When there are no conflicts, this value will be the same as the one given in the MIDI constructor. If there was a conflict, you should be given a value provided by the system.

The package supports the following CoreMIDI MIDIProtocolID values along with a legacy mode. These are encoded in the MIDIProto enum of MorkAndMIDI.

• MIDIProto.legacy -- use the older MIDIPacket format (MIDI v1 message format)
• MIDIProto.v1_0 -- use the newer MIDIEventPacket format with MIDI v1 messages (CoreMIDI MIDIProtocolID._1_0)
• MIDIProto.v2_0 -- use the newer MIDIEventPacket format with MIDI v2 messages (CoreMIDI MIDIProtocolID._2_0)

The legacy mode is probably the safest for now as it has had the most testing in my SoundFonts app.

The Receiver protocol defines functions that will be called for MIDI commands that arrive over USB or the network. Since they are all optional, you only need to implement the commands you want.

Note that at the moment, SysExc (0xF0) commands are not supported and are silently ignored. I have no need for them, but supporting them should not be too difficult a task -- you just need to buffer MIDI packets until it is complete.

The MIDI class listens for changes to the MIDI nework and creates / destroys connections to external devices when necessary. The Monitor protocol has methods you can implement to be notified when connections and/or devices change. There is also a way to track the MIDI channel being used by an external device.