Hi Rusty,
Glad to see you’re still at it. What were your plans for the MD+MC ?
With all these familiar faces, feels like i’m getting the band back together again.
- J
1 Like
I’ve got 2 1/2 MiniCommands, so I was looking at creating some mega firmware with three linked together, along with a gugabox SMD to control bunny rabbits and generate moonbeams… tie all that into an Octatrack, Rytm, Virus and Carbon… should be fun…
Vaugely interested in chipping in for a custom thingamajig… I’m a bit time poor right now for the obvious reasons… 
1 Like
Need to get hold of the schematics above ^ (For investigating putting a MiniCommand Kit together)
It’s not standard arduino hardware as it uses the ATmega64 microprocessor (for the 64K ROM flash) + SRAM
This kit might work with some tweaking, need to check pin outs etc…
–
Edit:
Looks like all the info we need is here:
https://drive.google.com/folderview?id=0B0urCULhoczcdXZVaFRoQzRwcEU&usp=sharing
Confirmed circuit diagram, pcb layout etc.
Looks like Wesen produced a custom board for the MC. Electrical engineers feel free to jump in here :D.
Might be easier trying to bootstrap the MidiCtrl framework on top of one of the higher spec arduino dev boards (with larger built in sram).
1 Like
Just a quick update:
I’ve successfully coded the exploit in to MinicommandLive (MCL). This required more time than expected, as I had to fix a nasty bug/feature in Wesen’s Midi stack that caused midi callbacks to behave strangely.
We can now reliably use the MachineDrum (MD) triggers as GUI input for MCL when the sequencer is running (without triggering internal sounds).
Storing tracks in the MC works as followed: Press the read button, then select the tracks to be stored by holding down the corresponding track triggers on the MD. Releasing all triggers stores the tracks.
Writing tracks to the MC works as followed: Press the write button, then hold down the tracks to be written by pressing the corresponding track triggers on the MD. Releasing all tracks writes the tracks to the MD.
I’ve started refactoring the code, debugging, removing excess, and hopefully freeing up more space.
Still a lot of work to be done.
Planned improvements:
-
Store master fx settings for each row (this would make MCL functionally equivalent to the +drive). If full pattern read, then store globals. If full pattern write then write global.
-
Add version information in project files.
-
Display overhaul (considering). Display row as a single 16 character line. One character/symbol representing each track type.
Second line of display will show full kit name. -
Synchronous muting during pattern write operations. Mute tracks and only unmute when at bar divisions of the sequencer.
5 Likes
Sounds great
1 Like
Another quick victory: Turbo Midi stable at 2x Speed.
The midi ctrl framework attempts to create a turbo midi link at 4x speed. I’ve discovered that this is just too much for the gutsy 16Mhz processor to handle, particularly when you have a lot of midi call backs going on. I’ve modified the TurboMidi classes such that the link connects at 2x and the link is stable.
TurboMidi is really essential as it makes the Kit and Pattern transfers between the minicommand and md much smoother.
It should be possible now to have a turbo midi link between the MC and MD, but have an external clock signal coming in at a regular midi speed on the MC 2nd input. Pretty cool!
1 Like
I’ve got one for sale. Let me know if you’re interested.
Daily Update:
Discovered that my Trigger Exploit breaks external sync.
Coming up with work-arounds…
1 Like
External sync work arounds works!
So we have turbo midi between MC and MCL at 2x (stable) with external clock coming in via regular midi signal.
The fix involves pausing and unpausing the sequencer in quick succession when executing the trigger exploit.
Clock seems pretty tight and I haven’t noticed any drift. Can probably code in a clock reset every 64 measures to keep it locked if we end up drifting apart.
–
Just noticed the occasional sysex error when running turbo 2x. bummer.
For the Machinedrum there are 4 possible error codes:
-1 length error
-2 checksum error
-3 memory full/position out of range
-4 version error
Seeing both 1 and 2 with turbo engaged, occasionally.
Going to be difficult to track this one down.
1 Like
Hey Justin, Rusty, Dub and co…
Been a long time for me also, great to see some Minicommand interest still out there. I still have mine although all my gear has been in storage for a while now 
, i’ve had to swap drum machines/synths for power tools (major house renovations)
I think the last thing I tried writing on the MC was a copy/port of the drum pattern generator similar to this, I got it working to a point and was quite fun but need to finish it off, i’ll holler back if/when I do get the time to complete it.
If anyone out there is up for the challenge of a DIY minicommand (and possibly re-design/enhance it?) then for extra credit - one game changing feature to add would be the ability to store/load multiple firmwares on the SD card… 
2 Likes
Hi Tyrone,
Good to see you back!
I am actively researching the easiest way to resurrect the Minicommand hardware.
The biggest issue thus far appears to be that no dev-boards have large amounts of SRAM.
Wesen expanded the microprocessor ram by adding in 128KB of external SRAM. .
Regarding improving the original design: I would like a larger LCD, more encoders, more buttons, another MIDI OUT. But it ends up being a new product.
Adding functionality to load firmwares off the SD Card would be cool. The bootloader would need to hold the SD Card libraries and they’re quite large. In short, I doubt there’s enough flash to accomplish this with the current microprocessor, perhaps one with larger flash storage could though!
2 Likes
Here’s an SRAM expansion board for the arduino. This should do the job of Wesen’s external SRAM.
1 Like
Daily Update:
Turbo Midi Fixed. Now connecting at 4x.
Tech Details:
Spent a romantic evening understanding the lower levels of the Midi Stack.
Fixing Read:
There are read and write ring buffers that are used to collect and send Midi data. The incoming buffer size was too small resulting in overflow and causing large sysesx data to become truncated at high Turbo Speeds.
Fixing Write:
The write commands of sysex were too fast. No delay between sends, and were relying on the speed of the midi link to throttle the data transfer. I’ve added in a delay that throttles the midi output such that the MD can handle the
sysex data no matter what the Turbo Speed.
More testing to follow here, but the logic is sound and Midi stack is no longer a mystery.
2 Likes
Yep, that was the reason given by Wesen way back when as to why its not possible in the current design… i’m no electrical engineer but yep it would seem that either more flash would be needed or smaller SD card libraries (if that’s even possible?). Food for thought anyway…
Hehe, yes I know exactly what you mean… So many times I have gotten to a point with firmwares where I’ve gone too far with overloads and combo button presses in order to be able to shoehorn in additional functionality, it gets impossible to remember what button/knob etc does what!
Nice, looks like you are smashing through those the framework bugs… 
1 Like
Luckily I have some engineering degrees under my belt.
Regarding the hardware diy/redesign. We have a few choices.
1) Try and get a 3rd party dev board with the original atmega64 processor working.
Code should work without problem as it is the same processor Wesen used for the MC
2) Try and get a 3rd party dev board with the atmega128 processor working (pin for pin compatible but with double flash storage for firmwares). Boot loader code might need to be modified as there is a small memory change as noted by atmega.
3) Try and get a dev board with atMega2560 Arduino Mega2560 working. (256kb of flash.)
The benefit of option 3 is that there is already an external SRAM shield being sold.
Which means no soldering.
LCD shields are also sold
SD card shields are sold.
If we went with option 1 or 2 I would have to design an SRAM circuit (not difficult, it’s in the microprocessor manual) but it would require somewhere in the order of 40+ solder points.
I’m leaning towards trying to get the Arduino Mega2560 working because of the available shields.
Any thoughts here would be great.
If the DIY project is to work then the build will need to be as easy as possible, with easily acquirable parts.
3 Likes
Mega would also be great for adding more encoders etc. It could also support a ‘classic’ version as well as a ‘Mark 2’ version with the appropriate enclosure and parts changes.
This would be so tempting if it went DIY, gnash teeth, rend garments. Always wanted to Command the MD.
At least I managed to dodge the Nava build. Which was hard because I wanted to see how the sampling part worked. Would love to build my own sampler.
2 Likes
Oh and by the way, for the new people, JV has some great liveset videos up on YouTube (or at least he did).
1 Like
Just put an order on ArduinoMega. Should arrive tomorrow. I’ll start hacking on the weekend.
2 Likes
Cool. I got one for a project a while back and it was like, yeah now we got some power.
Daily Update:
Trying to make MCL behaviour consistant, reliable and repeatable.
Bug fixes:
Imported MidiCtrl 0018 MidiUart.cpp as Wesen fixed some bugs relating to Midi send buffer and interrupts.
The previous code was causing turbo midi to die after sysex data was transmitted in certain situations.
Pattern read and write behaviour is now working correctly in scenarios:
MD -> MC sync (turbo on or off)
External -> MC SYNC (turbo on off)
Empty tracks are no longer written to the MD causing corrupt kit/patten data and md to lockup. Bad MCL v1.0 bug.
Issues:
Midi Machines cannot be detected as Trigger events.
Not sure how to work around this one, they transmit on their own channel. The velocity is different but it’s going to be difficult to differentiate between sequencer event and a user event.
1 Like