__ __| |           |  /_) |     ___|             |           |
       |   __ \   _ \  ' /  | |  / |      _ \ __ \   |      _` | __ \   __|
       |   | | |  __/  . \  |   <  |   |  __/ |   |  |     (   | |   |\__ \
      _|  _| |_|\___| _|\_\_|_|\_\\____|\___|_|  _| _____|\__,_|_.__/ ____/

NB : This page is about the IamForce "Proof Of Concept". If your are looking for the last version of IamForce, please check the documentation here.

IAMForce

This Proof of Concept shows how an AKAI MPC Live and a hacked Midiplus Smartpad can be mutated to simulate a Force controller. Even if this project was technically challenging, believe me, the original Akai Force product offers much more comfort for almost the same price...one less tinkering !!

The Akai Force is a great music creation instrument and brings a very cool user experience.

---

3 things were done to reach that goal:

1. hook up to Alsa APIs to reconfigure the Public and Private ports not accessibles from external applications
2. change hardware ids on the fly in sysex and in the system it-self
3. write a specific Kikpad firmware for the Smartpad to interpret MPC sysex

You will find the source of the "tkgl_iamforcectrl" LD_PRELOAD library here.

Hooking to Alsa APIs

MPC internal midi ports are opened as "rawmidi", inducing an exclusive access. It is therefore impossible to access it as long as the application owns it. First, 3 virtuals "rawmidi" ports are created, and thanks to a "hooked" snd_rawmidi_open Alsa function, waiting for the right port name, hardware "Public" and "Private" ports are replaced by our virtual ports handles.

Once the virtual ports are opened instead of their physical equivalent, it is necessary to reconnect them via Alsa sequencer to the hardware layer so that the midi messages circulate. This is done with a "aconnect" function that does roughly the same thing as the Alsa command line utility 'aconnect'.

Hopefully, creating a rawmidi virtual port uses the Alsa sequencer, and consequently, the port is not open in exclusive mode. So that permits to connect a second midi device : the Kikpad it self.

See :

• the "tkgl_init" function.
• the hooked snd_rawmidi_open

Change hardware ids on the fly

Hardware type is checked in 2 ways at any time by the MPC standalone application : by reading the product code at /sys/firmware/devicetree/base/inmusic,product-code, and with a midi identity request universal sysex message sent to the controller. If you tap on only one of these 2 identification mecanisms, either the application will switch to a classic "MPC" mode, or you won't be able to use the pads, because the application "knows" that you are not using the right controller.

Again, Alsa "snd_rawmidi_write" and "snd_rawmidi_read" are hooked with ld_preload, in "man in the middle" approach, to transform on the fly the sysex header from Force to MPC, and vice versa, so the flow is coherent in the 2 directions.

Concerning product code : the system "open64" and "read" functions are hooked too listening for an access to the "inmusic,product-code" file mentioned above. The "read" function is then forced to return the Force id, instead of reading the true MPC Live product on the filesystem.

See :

• snd_ramidi_read and snd_rawmidi_write hooked functions
• open64 hooked function
• read hooked function

Kikpad Firmware

As the Kikpad is connected to the MPC application thanks to our virtual ports, it is possible to send and receive midi messages as the MPC controller it self.

First, midi messages corresponding to pads and buttons must be implemented. Then as a receiver, the Kikpad must interpret sysex, or some special midi messages sent by the application, notably to show the right pads colors or to make a "tap tempo" led blinking. See :

• The sysex-parse function
• The blinking tap tempo
• The ForcePadSend that sends pads midi message

I hope these few hacking techniques will have interested you, but don't forget also to use your MPC to make music (or buy a Raspberry PI :-) ) !