How to upload midi files to your CME U-Key keyboard from linux

Context

The CME U-key is a cheap midi keyboard but is very convenient :

Unfortunately the tool named U-Brain to upload midi files to the keyboard is only available for windows.
I asked CME several time for information about the upload protocol with no response.
I had two solutions : to install a Windows machine or to hack some linux stuff to do the job. I of course selected to hack :-)

Prepare and upload a midi file to the CME U-Key

You can't upload a midi file directly to the U-Key as the midi file must be of a special format :

Thus you need to prepare your file before uploading, you can't get some midi files from the internet and upload them as-is.

Prepare your file to get a UK compatible midi file

Install the required software

The gory details about midi file upload to CME U-Key

The following sysex codes are used to send a file to the U-Key :

Header
appears only once at the beginning of the file transfer.
F0 00 20 63 00 01 00 02 00 song# 00 total block count 89 F7
F0 is the midi code for Sysex, 20 63 is CME manufacturer number song number between 01 and 0F   number of blocks that will be sent. Blocks are 1024 bytes long, except the last one which may be less F7 is for sysex end. Note that the 89 code used by CME is illegal if you consider the midi specification : SysEx content should be 7bits contents only, thus data bytes should be between 00 and 7F. This is a real problem with ALSA, see below.
Data block
Send as many Data blocks as they are 1024 bytes block in the 7bit encoded midi file.
F0 00 20 63 00 01 00 7F 00 song# 00 block# 89 data, up to 1024 bytes value maybe 00 to 7F F7
F0 is sysex, 20 63 is CME manufacturer number song number between 1 and 0F, should math the previously header   current block number, first block# is 0, last block is block count-1 The 89 illegal code The midi file may contain value greater than 7F so it has to be 7 bits encoded prior to be sent. Find the way it is 7bit encoded below. End of sysex

The following procedure is used to 7bit encode the midi file

On a 8 bytes sequence, the first byte encodes the heaviest bit of the following 7 bytes.

Let's explain this with an example, consider we want to send 8F 0F F7 70 70 FF 00.

Midi value (8bits)Binary valueresulting value
8F1000 11110F
0F0000 11110F
F71111 011177
700111 000070
700111 000070
FF1111 11117F
000000 000000
Resulting 1st byte
⇓    
 
 0 1 0 1 0 0 1 052
The data to be sent is 52 0F 0F 77 70 70 7F 00. You have to repeat this encoding for each 7 byte packets. For the last packet which maybe les than 7 bytes, just consider the last bytes are 00
Have a look at the uk7bits C source I provide, you may find it easier to understand. Lol !
Note it's not that often I can enjoy using the <<= operator :-).
It includes also the reverse encoding, available withe the -r comand line option. Enjoy ;-)

Software used to hack

Having no support from CME I had to drill down the stuff to determine what was the protocol used to upload.
Took me a lot of time.

I even had to bring back home some Windows XP laptop from work to do the job, that was very disgusting, I had to hide from my children ;-)

One major problem was to find out why the upload process failed even using the exact CME SysEx commands. The reason was usbmidi.c in ALSA source tree : when processing SysEx commands the usbmidi.c automat resets the sending loop when encountering an invalid hex value (between 80 and FF). Thus, when receiving the incorrect 89 hex value defined by CME, it ends abruptly the SysEx command, crashing the upload process.
To bypass this I send a 09 value instead, the U-Key keyboard interprets it correctly.
Windows doesn't care sending an invalid character in SysEx commands.

Windows software used

Linux Software used

Contact

I hope this hack will help you to make music with your U-Key :-)
As far as I've understood, this hack should also fit for VX keyboard but I couldn't test it.