TheKikGen
MPC Live - Internal Controller Details
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... :-)
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
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~~
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.
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....
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
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....
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.
