MPC Live - Internal Controller Details

[mungewell]

First Wow! Great work....

I started working out the control of my MPC Touch, which I'm guessing is the same hardware as used inside the MPC Live. https://github.com/mungewell/mpd-utils/tree/master/mpc_touch_reverse

Something I should get back to... :-)

[mungewell]

It would be interesting to know if the MPC Live controller also responds to 'all call' the same....

simon@thevoid:~/mpd-utils-git/mpc_touch_reverse$ amidi -p hw:1,0,0 -S 'F0 7e 00 06 01 f7' -r serial.bin
^C
35 bytes read
simon@thevoid:~/mpd-utils-git/mpc_touch_reverse$ hexdump -C serial.bin 
00000000  f0 7e 00 06 02 47 37 00  19 00 01 00 06 00 00 00  |.~...G7.........|
00000010  00 00 41 31 31 35 31 32  xx xx xx xx xx xx xx xx  |..A11512xxxxxxxx|
00000020  33 00 f7                                          |3..|
00000023

[mungewell]

I see you have made good progress, this is a gold mine: https://github.com/TheKikGen/MPC-LiveXplore/blob/master/mpc-live-sysex#L48

Just remember to strip out USB protocol stuff.... 0040 14 f0 47 7f 14 3b 64 00 14 03 00 01 16 01 f7 00 0050 14 f0 47 7f 14 3b 64 00 14 03 01 01 16 01 f7 00 0060 14 f0 47 7f 14 3b 64 00 14 03 02 00 16 00 f7 00 0070 14 f0 47 7f 14 3b 64 00 14 03 03 00 16 0a f7 00

[mungewell]

BTW the Touch presents 3 midi ports (in controller mode.... there is no other mode :-)

 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
 20:0    MPC Touch                        MPC Touch MIDI 1
 20:1    MPC Touch                        MPC Touch MIDI 2
 20:2    MPC Touch                        MPC Touch MIDI 3

The last of these is the in/out port (3.5mm jack) on the back of the device. I assume from your other comments that the Live's in/out ports are separate in the system.

[mungewell]

Played further with Midi sequences in your log, but unfortunately they did not seem to make a difference to the MPC Touch - with the ID changed to match Touch I did get a Midi response, just no apparent change on the device.

The MPC is still stuck at the 'blank' stage where the pad LEDs are not lit. I can control the display (see #2 ).

Through earlier brute forcing I noted the the MPC Touch responds (in Midi) to the following SysEx 'commands' 0x64, 0x50 (responds on 0x51) and 0x5a.

I suspect that the key is to get the device 'unlocked', in the stat where the pads are lit. Unfortunately the first midi port is hidden under Windows which means (so far) I have not been able to snoop communications.

Maybe this will be possible via the MPC (internal) command line, Midi or USB snooping.... 'we' might need to cause the control pad portion of the device to de/re-attach to observe what the MPC software does.

Detaching can probably be done in the software domain, by sending commands to the '/sys' interface. I'll see if I can dig how I've done that in the past....

[mungewell]

Didn't find 'my' way but this page suggests: https://stackoverflow.com/questions/45035048/how-to-disconnect-a-specific-usb-device-using-musb-hdrc-linux-driver

Once you figure out which device to poke....

# echo 0 > /sys/bus/usb/devices/2-1.2/authorized
# echo 1 > /sys/bus/usb/devices/2-1.2/authorized

[mungewell]

The penny has dropped, looking through the log again and reading this reversing of the Akai Fire: https://blog.segger.com/decoding-the-akai-fire-part-2/

I realized that that its the CC commands for lighting the button LEDS. Yeah!!

This lights the REC, OVERDUB, STOP and PLAY buttons: $ amidi -p hw:1,0,0 -S 'b0 49 01 b0 50 01 b0 51 03 b0 52 01'

From the above link, we might find that the Pad LEDs are done via SysEx....

[TheKikGen]

Note : MPC Touch hardware is very different than MPC Live Hardware. It is a DisplayLink device. No embedded ARM CPU, no Linux. Pads are identical. Screens seems to be.