MiniCommand Resurrection // MCLive


Small delay. Came up with a workaround for an important problem.


MCL 2.15 is released.

I strongly recommend all MegaCommand owners to upgrade to 2.15.
If you need help compiling and flashing the firmware you can shoot me a private message.

What gear would you like to see elektron do next?

Thanks for reminding me of this ! I’m a bit too lazy to read the whole topic now, but I’ll eventually do ! To order, should I PM you ?

Machinedrum source code / dream features

Version 2.16 has been released.

This mostly fixes issues with parameter locks on the sequencer not behaving predictably across writes or kit saves.


The GridPage is getting a GUI upgrade.

4 x 8 slots visible at a time with interactive cursor.



2.16a released

Small fix addressing write-original mode. Patterns would not restore correctly in certain circumstances.


Can’t compile -dev branch ATM because of

In file included from avr/cores/megacommand/MCL/A4Track.h:6:0,
                 from avr/cores/megacommand/MCL/Grid.h:7,
                 from avr/cores/megacommand/MCL/MCL.h:19,
                 from sketch/sketch.ino:1:
avr/cores/megacommand/MCL/ExtTrack.h:5:23: fatal error: GridTrack.h: No such file or directory

Sticking with (politically not correct) master for the time being.


Thanks. I’ve checked in the missing files to dev branch.

The next release will be 2.2 .

Earlier project versions won’t be compatible with the 2.2 release.
The project file layout has been altered for more efficient access to accommodate the new GridPage in addition to other improvements.

I haven’t finalised the project schema yet, which means project compatibility in DEV branch may change from patch to patch until we reach 2.2


Hadn’t had the time to really play with it yet, but am liking new GUI layout very, very much. Kinda proves that moving to OLED was THE right choice. Thanks for Your great work.


Good news.

Finally worked out a safe way to access the second memory bank on the megacommand.
This effectively doubles the available RAM capacity. I need the additional RAM to implement some fast caching behavior where the SDCard is too slow.

Switching memory banks is tricky because you need to ensure that no other program elements try and read/write to memory when you’re in the alternate bank. You also need to make sure that all stack memory is stored in a location unaffected by the bank change otherwise your program will crash.


Spent the week working on a new menu system for MCL.
Compatible with both displays…

I’ve now got a framework which allows me to define menus very very quickly.

This needed to be done to control some of the new features which will be present in 2.2.

  7 const menu_t slot_menu_layout PROGMEM = {
  8     "MENU NAME",
  9     8,
 10     {
 11         {"Load Project", 0, 0, (uint8_t *) &vars[0], (Page*) &load_proj_page, {}},
 12         {"ITEM 1", 16, 2,(uint8_t*) &vars[1], NULL, {{0, "opt 1"}, {3, "opt 2"}}},
 13         {"ITEM 2", 4, 2, (uint8_t*) &vars[2], NULL, {{0, "MIDI A"}, {1, "MIDI B"}}},
 14         {"ITEM 3", 1, 0, (uint8_t*) &vars[3], NULL, {}},
 15         {"ITEM 4", 1, 0, (uint8_t*) &vars[4], NULL, {}},
 16     }
 17 };
 18 ```


Just a quick announcement.

The new Grid GUI, memory enhancements and menu structure above was needed to implement a very cool enhancement to MCL, Chain Mode.

In 2.2 you will be able to configure each slot to automatically jump to another slot after N loops. Similar to an oldschool music tracker.

This allows you to construct songs, or automatically add variation to current patterns.

Due to the delay in transmitting pattern data to the MD, chain mode will only work for the MCL sequencer data, machine type and parameters do however load on the fly.

In light of the above restriction, I will add the ability to merge MD sequencer data with the MCL sequencer data and vice versa.


We just hit the biggest single win for MCL, in the entire development time.

Specifically, 8x TURBO is back and in a big way.

I was having a few lousy few days of coding. Struggling to get the performance from the Chain mode that I was looking for. Chain mode relies on being able to transmit parameter changes very quickly. But the timing of the changes was off, and I was unsatifised with the results.

I had spent an afternoon implementing delay compensation. Estimating the time it would take to transfer a collection of parameters, and then accounting for that delay appropriately.
It wasn’t really working and out of frustration I decided to measure the actual maximum byte rate that the MegaCommand was transmitting over MIDI.

My measurements for 4x TURBO were showing something between 5 and 10 KBps . This was surprising as I had expected the performance to be consitently closer to the theoretical max.

The actual max byte-rate for 4xTURBO is 12.5KBps ((31250 x 4) / 10) (each byte consists of 8 data bits + 1 start bit and 1 stop bit).

As expected, 8x turbo was performing similarly bad,

I spent a couple of hours looking at the interrupt code and rearranging things to win some small, but measurable improvements. Running out of solid ideas, I commented out a few lines of safety code that was written to prevent MIDI buffers from overflowing.
To my astonisment this had a signifiant impact on my throughput results, and then it occurred to me…

A few days ago, I noticed a clever line of code in some of the low level libraries that Wesen developed for MIDICtrl. The specific library was the ring buffer library. The ring buffers are the data structures that hold the MIDI send/and receive data.

#define RB_INC(x) (T)(((x) + 1) % N)

Wesen’s code is full of clever tricks of logic like this. What this macro does is increase the value x so that x < N; if x == N, reset x to 0

The mod operation includes division.

C = A % B is equivalent to C = A – B * (A / B).

and division of 16bit integers is extermely costly on an 8 bit micro-controller.

The above macro was being executed multiple times in the ring buffer code. Every time a byte needed to be transmitted or received at least one division operation was being performed.

Replacing the above macro with a standard approach, and we have gained full throughput for both 4x and 8x turbo (12.5KBps and 25KBps respectively). This not only increases transfer speeds, but it frees up an enormous amount of cpu time for other tasks.



From the last commits it is not clear to me if all the files referred were modified/checked in. I’m saying that because of somewhat high “\/\/TH factor” while reading latest diffs (or maybe I’m just durnb and this is a false alarm). Still, can You please doublecheck on Your side, Justin? TIA.

Meanwhile in dev branch… :wink:

avr/cores/megacommand/MCL/A4Track.h:9:23: fatal error: MCLMemory.h: No such file or directory

edit: ok NOW forum lets my post in. That was strange.


Thanks for that.

Uploaded a patch to DEV branch.

Chain Mode:

From the Grid Page, Shift2 button (bottom right), will toggle the chain menu for the current slot.

From here, you can activate global chain mode by setting Chain -> ON.

Set the number of loops, and destination slot for the jump.

The “Apply” value will apply the chain settings to N slots in the current row. So if you want to update an entire row set it to 16.

You can also choose to MERGE the MD sequencer data from the selected slot, in to the MCL sequencer.

Only data stored in the MCL sequencer will be chained. Chains only become active after a slot is loaded, through the Write page.

Still a work in progress…


Just a quick update.

Development stagnated over the last week as I spent hours tracking down a bug that was causing tracks to drift out of sync in chain mode.

This was a hard one. It turned out to be an issue with the MidiClock start code.

Now that is put to rest I can get back to progressing towards 2.0.

Will commit the changes to dev branch tomorrow.


Chain mode is progressing.

In normal operation writing a track sends pattern and kit data to the MD and then loads the internal sequencer data.

When in chain mode, only the internal sequencer data is loaded. And instead of transmitting the Kit, we now interleave machine parameter messages between 16th notes.

What’s cool about this is that we can now load MD tracks seamlessly . There is no audio pause or pattern/kit transmission delay when loading tracks…

As I mentioned in a previous post, it is now possible to merge the MD Sequencer data in to the Internal Sequencer. Playback sounds more or less identical.


Hi! are there still some MCL kit available for sale?


yes. pm me


we now interleave machine parameter messages between 16th notes. […] no audio pause or pattern/kit transmission delay

my 1st reaction to that was like: