Change MIDI velocity implementation to allow direct control of velocity value

[jakobkg]

Description

I've been trying to make a MIDI keyboard based on QMK, and one of the challenges of using mechanical keyboard switches for this is the lack of velocity sensitivity. To compensate, I was trying to add velocity control with an analog input, like a potentiometer. To my disappointment, I wasn't able to use my potentiometer to change velocity freely between 0-127, as the current implementation forces velocity down to a range of 1-10 which is far too low resolution for my wants and needs. These changes are an attempt at fixing this without breaking the current velocity keycodes, to allow the old method to work, and open up for setting velocity directly with something as simple as
midi_config.velocity = analogReadPin(POT_PIN) >> 3

My changes are at a relatively low level so I wanted to make this PR early so I don't put too much work in only to end up reworking them if they don't mesh well with the ongoing refactoring. As far as I can tell these parts of QMK are barely being used by any keymaps so I'm not super worried about them, but I understand that changes might be needed to preserve existing behaviour even better than what I have currently implemented.

As a side effect of my changes, the function compute_velocity() in process_midi.c is now only called when velocity is actually changed via the related keycodes, instead of being called on every MIDI note on or note off being message sent which should help performance a tiny bit.

I'm currently unsure if I have reached parity with how the existing MIDI_VELOCITY_MAX and MIDI_VELOCITY_MIN values are being used, but they don't seem to be very well implemented at the moment as it's possible to repeatedly press MI_VELU and have velocity overflow past 127 and wrap back to 0 which is very jarring. This behavior has been changed in this PR, to limit velocity values to 0-127 when being changed using these keycodes.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• None, this is an expansion on an existing, but not much used, feature

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[jakobkg]

I've done some further testing and the velocity values you can get using MI_VELU and MI_VELD before/after these changes are similar enough for this not to be disruptive to existing keyboards/keymaps.

With the current implementation, the velocity values available are:
12, 24, 36, 48, 60, 72, 84, 96, 108, 120
Continuing to press MI_VELU will allow the value to overflow past 127, which is undesired at best and could cause real problems if the receiving software doesn't handle the out-of-range velocity values gracefully.

With my implementation, the values available using MI_VELU/MI_VELD are:
0, 13, 26, 39, 52, 65, 78, 91, 104, 117, 127
Continuing to press MI_VELU has no effect once 127 is reached.

I recognize that this is 11 values and won't map well to the existing keycodes for MI_VEL_[1-10]. I think the solution here is to simply add the keycode MI_VEL_0, which sets MIDI velocity to 0.

[noroadsleft]

Thanks!