Bill of Materials + additional information provided below:
Total Cost:
Parts: $55 + Postage (USD)
Arduino Mega or Equiv: 10-$50 (USD)
PCB Fabrication (5 board minimum): $50-$70 (Postage included) (USD)
Total Min: $125 USD
Total Max: $175 USD
Enclosure cost: N/A
Total cost will be around $150 USD. If you decide to group buy PCBs, you can distribute the pcb cost amongst yourselves. The Arduino Mega price will vary depending if you want to buy an original unit or a equivalent knock off.
New PCBs + Parts + Enclosure have arrived.
I will build over the long weekend. Probably record the process for others to follow.
I’m thinking of making another small change to the PCB to allow for the installation of a 128 * 64 OLED panel instead of the 16x2 LCD. This will be optional.
Your wonderful!!
this is very cool … resurrection of the original project and outsourced in a modular futuristic-yet-sensible fashion. quite a magnificent, magical act of creativity and vibe. suitably fitting sequel to the original phenomenon of the Minicommand. 
yay
Forgot to say. I’m out of the country for 1 month.
I just uploaded the last revision of the PCB with OLED support and corrected an error with the power jack footprint. I still need to fabricate this pcb and test.
Unfortunately I ran out of time to test the last revision, so that will have to wait until I am back.
I’ll be at Moogfest if anyone wants to buy me a beer
aha the opportunity to visit the build-your-own-moog-drum-machine workshop perhaps.
although really with a machinedrum, who needs anything else?
have fun out there
Well. I’m back.
Need to go over the work I did before I left then send the board out for fab.
1.0.1 Boards are out for fab with support for an Adafruit OLED display 128 x 32.
Hoping this is the last hardware revision.
First of all, I must admit that You, Sir, are a gentleman and a scholar, and this topic should probably serve as an etalon for projects alike.
Now the only thing which stops me from buying everything that was mentioned here (e.g. used MD SPS-1 mkII UW+, MegaCommand components and -808 & -909 MD soundpacks) is that dreaded MD limitation that all tracks must have the same length, and unfortunately it’s a biggie. AFAIK the latter limitation can not be lifted (oh please please someone tell me that I am wrong and there’s a way), and it makes polyRhYThMs impossible. A deal breaker for me.
Edited to add: Oh wait. Also there’s no conditional trigs on MD. Sigh.
Conditional trigs could be implemented quite reliably. I already have routines that mute and unmute tracks on precise step counts. The trigger interface could be used to select the step number. Small complication here in that the mute state of the MD is never precisely known. There are other tricks to mute a track which may be appropriate, like set the volume to zero or momentarily change the track machine to a Midi machine or something harmless.
Regarding different track lengths I’d imagine this is possible to do as well. For instance, I previously had a routine that would loop the first 2,4 or 8 steps of a track across the entire pattern length. Using this as a starting point, track length would be equal to the loop length.
Things get a little complicated when the track length is not a multiple of the pattern length. The p+ and p- modes of MCL allow for preparing the next pattern before switching to it, i’d imagine using this feature with additional code: patterns could be dynamically generated to emulate different track lengths.
Sht’s getting real here in the Other Gear forum 
Started porting over the MIDI_CTRL framework to the Arduino IDE and supporting the Atmeg2560 processor.
So many compiler errors 
hope all that effort would be worth your time. i tend to get around the conditional trigs limitation with LFOs, and an OT sequencer can give you track length options. but to get all of this with just an MC… wow. just wow. my gratitude for even considering it.
This is subjective. Probably not worth my time at all, but I am enjoying the challenge.
Still sifting through Compiler and Linking errors, quite painful really.
I got the MidiCTRL framework to compile and link inside Arduino IDE after much refactoring 
Linking everything together…
“/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-gcc” -Wall -Wextra -Os -flto -fuse-linker-plugin -Wl,–gc-sections,–relax -mmcu=atmega2560 -o “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/sketch_jun10a.ino.elf” “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/sketch/sketch_jun10a.ino.cpp.o” “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/core/core.a” “-L/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991” -lm
“/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-objcopy” -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/sketch_jun10a.ino.elf” “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/sketch_jun10a.ino.eep”
“/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-objcopy” -O ihex -R .eeprom “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/sketch_jun10a.ino.elf” “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_559991/sketch_jun10a.ino.hex”
Sketch uses 9030 bytes (3%) of program storage space. Maximum is 253952 bytes.
Global variables use 28342 bytes (345%) of dynamic memory, leaving -20150 bytes for local variables. Maximum is 8192 bytes.
Not enough memory; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing your footprint.
Error compiling for board MegaCommand.
Still need to work out the PROGMEM memory issue above ^.
Understand nothing, but looks impressive to me…
MIDI Ctrl compiles and uploads to the MegaCommand.
I also got MCL firmware to compile and upload. Need to modify elements of the core for pin changes.
“/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-objcopy” -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_761308/mcl.ino.elf” “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_761308/mcl.ino.eep”
“/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-objcopy” -O ihex -R .eeprom “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_761308/mcl.ino.elf” “/var/folders/0q/mn27032j7bqch7d_krf2603c0000gn/T/arduino_build_761308/mcl.ino.hex”
Sketch uses 47734 bytes (18%) of program storage space. Maximum is 253952 bytes.
Global variables use 56335 bytes (92%) of dynamic memory, leaving 4665 bytes for local variables. Maximum is 61000 bytes.
We’re fully functional on the ArduinoMEGA:
SDCard, Midi, LCD, Encoders/Buttons, SRAM all working.
Porting over the core was as agonising as I imagined it would be, but we got there.
Image above shows the MiniCommandLive firmware running and communicating with the MD.
I can answer your question now, 1 year to the day.
Yes!
Last pcb revision has an error, the OLED display port is around the wrong way.
I’ve tested the OLED and it works and looks amazing.
