Page 1 of 1

The inconsistent velocity issue - a possible solution!

Posted: Mon Jun 09, 2014 11:40 am
by ajaym
Ok, so I have pretty much solved the tilt problem - I'll post my Reaper JS here shortly on the appropriate thread. But before I am done I really wanted also to solve the issue that many people (including myself) appear to have had, namely that key velocity sensitivities are not consistent across the device and cannot be fully compensated for by using the key sensitivity settings in the Qunexus editor.

Now, I have had the good fortune to be able to play with three Qunexus devices. The first one of these I returned because when one key was set to maximum sensitivity it would start randomly flashing and playing notes - oddly enough, even when set to max sensitivity it was still noticeably less sensitive in terms of maximum velocity than other keys.

Turning the keyboard upside down stopped the flashing, so clearly the setting from the qunexus editor is ramping up some kind of analogue gain control inside the unit on a per-key level. But in the case of the faulty key, this simply made the unit susceptible to false triggering yet - oddly - did not actually fix the velocity range issue at all.

Anyway, I returned the unit and purchased a second one (so now I have two new devices). Because - 4 octaves in a backpack!. Awesome. I can actually play proper keyboard parts and I am really impressed. Obviously since I just parted with 300 quid where in the UK US dollars turn into pounds (sigh!), you can figure I'm pretty impressed - but I really want to fix the inconsistent key velocity issues because all three units had between 2 and 3 keys each where sensitivity is noticeably lower and could not be fully corrected by adjusting the key sensitivity in the editor.

On the way to work this morning the solution came to me. I've experimented enough to know it will work, in theory, but have not yet fully implemented it.

The plan is to exploit the controller layer functionality of the device, coupled with some MIDI modifications through a JS plugin for Reaper. These should easily be translateable into a VST plugin for hosts that don't have this kind of functionality, but that - I hope - I may be able to pursuade KMI's engineers to tackle since, although I could easily write one myself, I don't need a VST in Reaper to do this.

So the idea is this. I tested the first part. Set up every key to transmit on both the keyboard and controller layers. Set each key to transmit no tilt or pressure on the controller layer but just note 1 (in MIDI this is way way below the lowest key on the piano - which is, I think, note 22). This is quite simple - you can select multiple keys by shift-clicking so setting the whole thing up is quite quick.

Now the trick here is that the VELOCITY of each controller layer note can be set independently. It will allow a key scaling factor to be defined on a per-note basis and saved as part of the preset (I'm using preset D for testing).

Unfortunately KMI's engineers chose to send the control layer AFTER the keyboard layer - which is a shame because it makes my life a little more complex. But essentially the idea is to look for MIDI note 1 and record the velocity as a correction factor. When the plugin is first used it'll be necessary to play each key once so that the correction factors can be stored (and then saved to a lookup table file for the device).
Or, it could just not scale the note until it's played the second time - that would probably be ok most of the time.
(I wouldn't have this limitation if the control layer was sent first - KMI? - any chance of a firmware option for this).

Then from that point, when a note is played, we will scale the MIDI velocity by the correction factor. We throw away the MIDI note 1 event, of course, we just want its velocity value.

Having looked at how these keys behave, I suspect the best approach is to leave all notes below approximately velocity level 20 or so unaltered - even weak keys seem to be fairly even at low velocity levels. After this threshold, multiply the MIDI velocity by the correction factor. To allow scaling both up and down - for perfect even-ness - a control layer value of 64 will represent a scaling factor of 1.0 and values lower than this will represent scaling factors less than 1 and values higher than this scaling factors > 1. I think a range of 0.5 - 2.0 will suffice - I haven't seen any weak keys that are beyond these limits.

The beauty of this is that the controller layer is not affected by octave shifts so velocity correction is - correctly - applied to the physical key. It is also stored per Qunexus in the patch - so you can set up multiple units and scale each one. And it is a one time operation.

I'd obviously prefer not to have to do this - KMI - are you listening - can't we have per-key scaling in the editor and implemented in the firmware AS WELL as key sensitivity - but this approach should work

It will be a slightly tedious one time effort to calculate the correction factors for each note but at least that can be done using the Qunexus editor - the plugin will simply take the values and use them after they change.

I should have this working in the next few days and will post back when I have some working JS code - which, in Reaper is just a text file. The single plugin will fix the tilt issue as well (discussed elsewhere).

Now - I would have liked a way of automatically defining the scaling constants. Unfortunately my cunning plan - to drop something soft (I tried a plastic dice) onto the keyboard from a fixed height - doesn't seem to work as well as I had hoped. But possibly if I tried a ball-bearing or something that fitted into a plastic tube like a pen barrel, that might work better - stopping it bouncing off in odd directions. It would be nice to just have a simple way to hit each key with a fixed velocity and then read off the velocity and determine the scaling factor for each key to even them up.