MPC-Studio-Mk2-Midi-Sysex-Charts

In this repository, you will find the breakdown of the MIDI Note, CC, and Sysex data for the Akai MPC Studio Mk2. This is in no way sponsored by Akai.I'm actually a frustrated buyer and user of this product.

My attempts to use this product with other software left me very frustrated. Without the brains of the MPC 2 software, this device on its own is useless. It sends out midi data, but not in a way that is remotely usable. I fault Akai for this. It would have been very easy and simple for them to make a controller mode for this unit, and release MIDI technical specs in a PDF but they have not done so.

Through sending and observing MIDI data to and from the device, I have discovered that this is a "dumb" device. There is no logic on the device to perform any of it's functions or feedback, it is all controled by the software(MPC 2) through MIDI. That means if I can figure out what MIDI messages, I can program the device with other software... hint hint.. Ableton Live...

This repository is the result of me doing just that. I have figured out every element of the MPC Studio Mk2 with the exception of the LED display. Any help is appreciated. Enjoy!

Config

• You must use the Public port on the MPC Studio Mk2.
• The private port is only for the MPC Software

Buttons

• Buttons send data on channel 1 (channel 0 if you're in code)
• Buttons send MIDI note data.
  • On = 127
  • Off = 0
• The Button Backlit LEDs are controlled through CC data, using the CC# that correspond to the midi note.
  • Example. Pressing Note Repeat sends MIDI Note D -2 . The numerical value of this note is 11. Thus the NoteRepeat button's LED will respond on MIDI CHannel 1, CC#: 11
• LED CC Values: These LEDs do not seem to be RGB. There are two types of LEDS on this device. Single Color, Two Color. Listed below are the CC values for each type:

One Color LED

Two Color LED

Here is a full breakdown of the button Midi Note and CC values.

Button Note - LED Table

Touch Strip

The touchstrip's note on and off may very depending on MPC Software setting. The intial touch sends a Midi Note-On msg and sliding your finger up and down send CC messages.

Touch Strip Chart

When using the touch strip in the MPC software, you get feedback on the control via Red dots and the Note Repeat Values. This can also be manually lit up on indiviual CC values with brightness from 0-127. Yes... all this is done by the software and not in hardware. If you want to emulate this, you'll need to do it manually but it's possible. Here is the breakdown

Touch Stip LED Chart

Jog Wheel

The Jog wheel is pretty straight forward. Nothing out of the ordinary here

• Turning it send a Midi CC message on CC# 100. Clockwise sends a value of 1. Counterclock sends a value of 127
• Pressing the Jog Wheel sends a Note on/off value of MIDI Note 111/D#7

Pads

What we've all been waiting for... Those delicious MPC Studio Mk2 Pads... All jokes aside, they do feel nice to play on the LED feedback is wonderful. This was the hardest part to figure out but I finally got it. At the beginning of this document, I made the observation that there is no logic on this device that provides any of the feedback you get when using it with the MPC Software. This is even true for the pads.

The Pads by default send Midi Note data when played and pressure-sensetive, aftertouch values. The LEDs however are not controlled from the device, but rather through sysex messages sent back to the device while playing... Yeah you got it... When you play a note, the software receives that note and send a MIDI sysex message back to the device to tell the PAD LED what color to show and how bright.

This device really is a dumb device. To my knowledge there is no mode to set the pads to automatically do this. Feedback is welcomed. If you find anything different, let me know by submitting an issue to this repository. I did however figure out the sysex messages for the pads and how to send them to the device to mimic this behavior.

• Pad Numbers in code start at 0 and go to 15. So Pad 1 on the device, in code, is actually PAD 0. Thats how it is addressed in sysex messages too. Pad 1 in sysex code is 00 . Thats hexadecimal for the value 0

PAD LED Sysex break down

Sysex data is sent in hex bytes ranging from 0-127 with start bytes and end bytes. Here is the PAD Color Code

F0 47 47 4A 65 00 04 00 7F 00 00 F7

The above sysex message will turn Pad 0 to bright red. The device will accept any combination of RGB values, so the pads could technically be whatever color you want. The values for Red Green, and Blue are 0-127 for each. If you're sending this to the device manually you will have to convert the numerical/decimal value to a hexadecimal value, so 127 is actuall 7F. Most scripting languages can do this conversion for you.

With the knowledge of how the Pad LEDs work and a little python skill, I have created a replica program that allows me to play the pads and get LED feedback in the color of my choosing. You would think that all the traffic back and forth from the computer would introduce latency with the LED response, but that's not the case at all.

PAD Led Sysex Cheat

Pad Note Chart

Here are the Pad notes. When you strike a pad, these are the note values that are sent to the host.

LCD Screen

We have finally figured out how to operate the LCD Screen on the MPC Studio Mk2. Thanks to @gstepniewski and @BlackBinary for their help in reverse engineering the LCD Screen

Overview

The LCD screen works by sending 160x80 pixel PNG encoded images via SYSEX midi messages. However, it is not as simple as sending the bytes of a PNG message in a Sysex message after the header. The PNG must first be encoded to a format that is transmissible via MIDI. MIDI bytes are limited to 7bit, where as most modern image formats start at 8 bit/1byte values.

Also, the image is not sent as one complete 160x80 png file. The image must be broken up into chunks. Each chunk is it's own png file and then encoded for transmission via MIDI. A sysex header and metadata is generated per chunk, and the message is sent to the device.

Each chunk has specified coordinates of the total image.

The X,Y coordinates for the chunks are listed below as X1, Y1, X2, Y2:

X1:0,   Y1: 0,  X2: 60,  Y2: 60
X1:0,   Y1: 60, X2: 60,  Y2: 80
X1:60,  Y1: 0,  X2: 120, Y2: 60
X1:60,  Y1: 60, X2: 120, Y2: 80
X1:120, Y1: 0,  X2: 160, Y2: 60
X1:120, Y1: 60, X2: 160, Y2: 80

The next obstacle to overcome is the Sysex header file and metadata per image. Each chunk sent must include metadata about the image chunk being sent. The formula for the generating the metatdata is listed below is sequence of bytes.

Sysex LCD Chunk Header

Sysex LCD Chunk Metadata

Sysex LCD Chunk Payload.

The payload for the sysex chunk is an PNG image complete with standard PNG image headers, compression data, etc. Essentially, everything related to a PNG file is in the payload. The only difference is that we must encode the PNG data in 7bit representation, which means we must do some bit shifting to make this possible.

The developers at Akai chose to use a control byte for every 7 bytes. This allows them to encode values greater than 127(0x7F) in the sysex message. The process is to loop over the bytes in sets of 7 in the PNG image. If the byte is larger than 127, the control bit is set to 1 and then shifted into position of the byte in the group of 7. The byte that was larger has 128 subtracted from it. Once the the group of 7 is complete, the control byte is pushed to a new buffer, followed by the 7 bytes, and the process continues for the next 7 bytes. Here is the logic implementation in Go:

func encode_png(original_png_buffer []byte) []byte {
    var encode_png_buffer []byte
    stride := 7
    for i := 0; i < len(original_png_buffer); i += stride {
        end := i + stride
        if end > len(original_png_buffer) {
            end = len(original_png_buffer)
        }
        group := original_png_buffer[i:end]
        control_byte := 0

        for j := 0; j < len(group); j++ {
            if group[j] >= 128 {
                control_byte |= 1 << j
                group[j] -= 128
            }
        }
        encode_png_buffer = append(encode_png_buffer, byte(control_byte))
        encode_png_buffer = append(encode_png_buffer, group...)
    }
    return encode_png_buffer
}

This will encode the PNG chunk to a format that can be sent via sysex. The same logic can be implemented in any language of your choosing.

Sysex Complete Message

Once the header, metadata, and payload have been generated, you can now concatenate the three sections, and append it with the sysex end byte (0xF7), and send it to the MPC Studio Mk2

var msg []byte
msg = append(msg, header...)
msg = append(msg, metadata...)
msg = append(msg, payload...)
msg = append(msg, byte(0xF7))

This process will be done 6 times per frame sent to the device. There is no need to refresh the screen with a frame rate. The image will be displayed until you send another image, reset the device, or another programs takes control.

POC (Proof of Concept)

Included in this repository are two POCs as demos of the screen being controlled by custom code. The first is in Javascript, using the sharp library and showing white noise on the screen. The second is in Go using mostly native imaging capabilities, and shows the control values as you press buttons on the device.

I'll be working on a Python, and C++ implementation POC for the LCD Screen as well.

This can be implemented in any programming language that supports midi, and imaging to some degree. Most of the performant imaging libraries are written on lower level languages, so it will be difficult to incorporate the screen in our custom MIDI scripts in the DAW. Most of the scripting environments don't allow to import libraries with C/C++ bindings.