Repurposing a Maschine Mikro Mk2 controller to drive a Microcontroller MIDI sequencer or CV/Trigger outputs (and learn Rust)
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
Initial work is to develop the software to handle the protocol that the controller uses (thanks to the cabl project for a big head start on this) and enable full functionality of the device before producing a simple sequencer prototype that utilises the capabilities of the device (the display is a huge help here for providing output).
Phase two involves porting the software to run on a Raspberry Pi Pico.
With the driver from the PC working and all of the buttons, LEDs, encoders and display working the next step is to get the sequencer and DAC side of things going.
This is where I have started running into problems...
The first issue, the interface would partially startup but the micro would crash, suspected this might have been a power issue, and yes adding a separate 5V power supply solved that.
The second issue, when plugged into the micro the Maschine controller doesn't identify as a HID device. This is an issue I've not yet been able to solve. Have used Wireshark to capture all comms when plugged into the PC and the 2 USB Interface descriptors are returned one a custom interface and the second being HID, however connecting to the Pico only the custom interface descriptor is reported. Am at a loss to work out why.
If anybody has more expertise on the behaviour of USB I'd be interested to hear, I have picked up a lot about the ins and outs of USB but there is a lot of details I'm sure I've missed with the breadth of details that go into the protocol. I've also learnt a lot about the TinyUSB stack which may necessitate some contributions to the USB master side of things.
Now that I have a display with font rendering and certain effects (eg invert) I can start looking at building a UI.
The UI will make use of the 8-bit line-height to divide the display into 8 rows of text, many queues will be taken from the machines original UI, eg tabs that correspond to the F1-3 keys.
The initial work now provides a scrollable text panel, I've identified the following basic components:
- Tab panel
- List view
- Sequence grid
I have already identified some features required in the display rendering from developing components.
Once I have a basic UI working the next step is the sequencer itself. At this point, custom hardware and a switch to embedded development will really be required.
Following the last post on working out how the display data is formatted, I have come up with a better description of how the data is formatted.
The display is made up of rows, each row is made up of 128 bytes where each byte defines 8 vertical pixels.
On the Maschine Mikro Mk2 that means that 8 rows (64pixels) are required for the whole display.
In addition, each USB report can send up 256bytes of row data so an entire screen refresh requires 4 reports.
The Report header
After mucking around with the header fields I have managed to determine what each of them do
| Field | Type | Description |
|---|---|---|
| Address | uint8 | Display or Message type identifier (0xE0 for the display) |
| Column Offset | uint8 | A column within a row to insert pixel data |
| - | uint8 | Possibly a high byte for the previous field for larger displays, set to 0 |
| Row Offset | uint8 | Row from the top to insert pixel data |
| - | uint8 | Possibly a high byte for the previous field for larger displays, set to 0 |
| Row Width | uint8 | Width of each row in pixel data (allows for partial row updates) |
| - | uint8 | Possibly a high byte for the previous field for larger displays, set to 0 |
| Row Count | uint8 | Number of rows in pixel data, for a full row this would be 2, must be at least 1. |
| - | uint | Possibly a high byte for the previous field for larger displays, set to 0 |
Following the header is up to 256 bytes of pixel data.
The following rules apply, Row Width x Row Count must be <= 256. So an entire vertical slice of the display can be updated by setting with width to 0x20 and the row count to 0x08.
A bit of thought was obviously put into the layout of the display. The display uses 1 bit per pixel but it is broken up into 8 pixel bands where each byte in the display buffer represents 8 vertical pixels with 128 bytes making up a full stripe. This is a clever design as it allows for characters to be easily much easily rendered (as long as they are 8 bits high) and allows for simple updates to small blocks of the display (eg the current time code) without sending the entire display buffer.
I still need to do some investigation of the display header to determine what all of the various fields are used for, I am assuming one will be an offset within the pixel buffer for doing partial updates.
To accommodate this I've added a single file program for converting the output from GIMP's export as C-Header into a pixel buffer that can be rendered to the display.
Looping through all of the LED's for the RGB LEDs (pads + the Group Button) a random colour is generated.
Tim Savage
Splendide_Mendax
Gabriel F
clarkhensley
sjm4306