MegaCommand // MiniCommand Resurrection // MCLive

It’s unfortunate that Elektron have not made MIDI a priority on the new machines.

From working closely with the MD you can see their was great care and attention to make the MIDI spec as comprehensive as possible.

1 Like

Unfortunately I can’t compile latest -dev as it is ATM, 'cause it says:

In file included from avr/cores/megacommand/MCL/MCLSeq.h:6:0,
                 from avr/cores/megacommand/MCL/MCL.h:21,
                      avr/cores/megacommand/MCL/SeqPages.h:26:24:
fatal error: SeqLFOPage.h: No such file or directory

And yes, there’s no such file there.

If I comment out lines 26 & 36 in avr/cores/megacommand/MCL/SeqPages.h that reference it, then the sketch seems to compile:

Sketch uses 122480 bytes (48%) of program storage space. Maximum is 253952 bytes.
Global variables use 45429 bytes (79%) of dynamic memory, leaving 11914 bytes for local variables. Maximum is 57343 bytes.

Should I try to upload it in such a “state” or not? :wink:

Yeah that’s fine. I need to remove the references to those pages before merging to master.

Edit: Just uploaded a patch for this.

1 Like

Update: I’ve spent the last 2-3 weeks re-itterating over firmware features, fixing bugs and improving workflow and stability. I’m very happy where the firmware is now.

I plan to release 2.15 tomorrow.

6 Likes

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.

2 Likes

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 ?

1 Like

Version 2.16 has been released.

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

2 Likes


The GridPage is getting a GUI upgrade.

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

gridpage3

6 Likes

2.16a released

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

1 Like

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

3 Likes

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.

1 Like

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.

6 Likes

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 ```
3 Likes

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.

6 Likes

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.

:smiley:

15 Likes

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…

2 Likes

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.

4 Likes