Add support for MIDI devices

[neilenns]

Is your feature request related to a problem? Please describe.
There are lots of midi devices out there that are essentially big boxes of buttons, encoders, and switches. The new Joystick feature laid the foundation for supporting devices like this. A couple of people have asked for MIDI support in the Discord now.

Describe the solution you'd like

Buttons/encoders/etc. on midi devices show up as inputs in MobiFlight
LEDs on midi devices show up as outputs in MobiFlight (is that even possible?)

Additional context

Here's a C# library that looks useful: https://melanchall.github.io/drywetmidi/articles/devices/Overview.html

[Koseng]

The MIDI stuff seems to be pretty simple.

Midiconnetion code for X-Touch-Mini-FS2020 in python:
https://github.com/maartentamboer/X-Touch-Mini-FS2020/blob/main/midiconnection.py

You get MIDI Messages from the device:

• “Note On Event”-Message for Button pressed
• “Note Off Event”-Message for Button released
• “Control Change”-Message for moving or turning fader or encoder.

[Koseng]

Output from X-Touch-Mini-FS2020 Application:

Startup:

Midi input devices: ['X-TOUCH MINI 0']
Midi output devices: ['Microsoft GS Wavetable Synth 0', 'X-TOUCH MINI 1']
Using midi input device: X-TOUCH MINI 0
Using midi output device: X-TOUCH MINI 1 

Button pressed and released:

note_on channel=10 note=15 velocity=127 time=0  (Button with ID 15 is pressed down. velocity just max value)
note_off channel=10 note=15 velocity=0 time=0  (Button with ID 15 is released. velocity just min value)

Encoder turned. Encoder configured in relative, endless mode:
Value range is 0..127. In relative mode 64 is basically neutral.

control_change channel=10 control=7 value=65 time=0   (Encoder with ID 10 was turned right one increment value for right 65)
control_change channel=10 control=7 value=65 time=0   (Encoder with ID 10 was turned right one increment value for right 65)
control_change channel=10 control=7 value=65 time=0   (Encoder with ID 10 was turned right one increment value for right 65)
control_change channel=10 control=7 value=63 time=0   (Encoder with ID 10 was turned left one increment value for left 63)
control_change channel=10 control=7 value=63 time=0   (Encoder with ID 10 was turned left one increment value for left 63)
=> If the encoder is turned faster, the values for “right” increase and the values for “left” decrease e.g.
control_change channel=10 control=7 value=59 time=0  (turn left)
control_change channel=10 control=7 value=59 time=0   (turn left)
control_change channel=10 control=7 value=67 time=0  (turn right)
control_change channel=10 control=7 value=67 time=0  (turn right)

Fader. The fader has values from 0 to 127:
When moving fader:

control_change channel=10 control=9 value=67 time=0
control_change channel=10 control=9 value=66 time=0
control_change channel=10 control=9 value=65 time=0
control_change channel=10 control=9 value=64 time=0
control_change channel=10 control=9 value=63 time=0
control_change channel=10 control=9 value=62 time=0
control_change channel=10 control=9 value=61 time=0
control_change channel=10 control=9 value=60 time=0
control_change channel=10 control=9 value=59 time=0

[Koseng]

Some Midi Spec:
https://www.midi.org/specifications-old/item/table-2-expanded-messages-list-status-bytes
https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message

---

This is what I like best by far for a possible MobiFlight use case:
https://github.com/codewitch-honey-crisis/MidiSlicer

• Very well documented (linked article at codeproject)
• Very lightweight (library is just the "Midi" Project)
• Many examples (Receiving messages "MidiMonitor" Project)
• MIT license

[neilenns]

This was completed with #561

[jcallano]

There are SysEx messages on the MIDI protocol, enabling fast bidirectional information exchange. Can the feasibility of implementation be assessed?

[Koseng]

hi, with the currently used library it is not possible. The library does not properly support SysEx messages. I have another library in mind for the future, but did not have time to try it, and it currently is no priority.

Also probably doing SysEx via configuration is very hard, since the messages can be so different.

What is your concrete use case?

[Koseng]

Ah ok you want to use midi to transfer flightsim variable values?

[jcallano]

Yes, build sim Hardware using Midi for data exchange

[jonas-koeritz]

I second this, it would be nice to have the option to just send numerical values (0 to 127) for note and velocity as note messages to an attached device. This would enable an easy method of building peripherals where no modifications to the MF firmware are necessary to support a multitude of devices.

[AfromD]

Thirded... :) I have a 3rd party legacy device that provides inputs and displays outputs, all not directly compatible with mobiflight firmware. It would be great if I could send 7 bit values back to the hardware. I could then code my own microcontroller that can communicate with mobiflight connector through midi. Programming for this is easier than modifying the MF firmware to do what I need.

Edit: looking at the source code, it would already help if the setting of the led on value was not mandatory, and allowing to pass a value in stead of a led status. So if no led Valueon or Valueoff are defined in the json, treat it as a numeric 0-127 output, and pass it as is. That way it could be used to transmit a digit, half a frequency or similar.

Just for fun, I asked ChatGPT for its thoughts on how to use the current tri state led channels to encode a frequency, here is what it came up with, needs 7 leds on the Connector end....

... disregard

[AfromD]

Ouch, just found out that you can't put on state and blink state in one output configuration, but it is an output of its own. So Binary output via MIDI seems to most that can be had currently :(