
Here is a short summary of the MIDI messages that I observed.
#Akai midi monitor Pc#
If I want to use MIDI-OX on PC for monitoring, I’ll need to try another USB MIDI interface (perhaps my old EMU). I couldn’t get a Sparkfun breakout board to work with the UM-2EX either. I can only surmise that my Roland (Edirol) UM-2EX MIDI interface cannot detect the signal transmitted by the UBLD.IT. Success, again! Now I can see the MIDI messages and, indeed, they are targeted for SAM2635. The MIDI interface in this case is an old IK Multimedia iRig MIDI. Instead of monitoring the MIDI message stream via MIDI-OX on a Windows PC, I used the LOG display in the MIDI Designer app on iPad. Success! The Akai Mini Play can play notes and change patches on the Genos. I sent MIDI from the UBLD.IT to the Genos MIDI IN port. I connected the MIDI signal to the MIDI OUT side of the UBLD.IT MIDI breakout board. The MIDI is there I just need to sense it properly.
#Akai midi monitor serial#
I estimated 8 serial bits per oscilloscope time division (256 usec). Yes, I found data and the data are repeatable, i.e., hit a C on the keyboard and you get the same bit sequence every time. I switched the Gabotronics to logic analyzer mode and observed the serial data signal. The protocol sniffer displayed HEX gibberish at 34,800. The 200,000 baud rate is reserved for USB debug, so it’s use is unlikely in this case. Unfortunately, the Gabotronics protocol sniffer does not support the standard MIDI baud rate, 31,250 baud. I tried the Gabotronics protocol sniffer. I performed additional experiments which eventually paid off.įirst, I observed the signal from Arm TX to the SAM2635 MIDI IN (RX) pin using a Gabotronics Xminilab USB oscilloscope and logic analyzer. (USB messages are sent when INTERNAL SOUNDS are OFF.) Persistence leads to discoveryĪt the end of my second post, I noted my failure to monitor the message traffic from the Arm to the SAM2635. They are not the same as the messages sent through the USB port, i.e., the user-defined MIDI CCs, etc.

These MIDI messages are encoded for and are meaningful to the SAM2635.
#Akai midi monitor software#
When INTERNAL SOUNDS are enabled, the key strikes, pad hits, knob turns and joystick movements cause the Arm software to transmit MIDI messages to the SAM2635. A future post will address the case when INTERNAL SOUNDS are turned OFF. For this round of analysis, Mini Play INTERNAL SOUNDS are turned ON. The Arm microcontroller sends MIDI messages to the SAM2635.

SAM2635 synthesis chip: Arm TX -> MIDI IN (RX) Dream The second post, in particular, shows how I brought the internal MIDI signals out from the main printed circuit board.įor the moment, I am focused on the communication between the Arm microcontroller and the Dream S.A.S. Before reading ahead, I recommend reading my previous posts about Akai MPK Mini Play internals: I’m happy to report progress with breaking out the internal MIDI traffic within the Akai MPK Mini Play (first generation).
