DEV branch is stable now.
Read the Changelog before using.
If you’re planning on using the WavDesigner there is a nasty bug in the MD firmware that causes the MD encoders to lock up after receiving a sample dump in certain scenarios. The Changelog has more details.
Should add:
The WAVDesigner mode has 4 pages.
OscPages:
Encoder buttons[1-3] select oscillators [1-3].
Top left button changes wav type.
Certain wav types use the MD trigger interface (Sine and User) + modifier encoder (see below)
Encoder 1 = Pitch/Note (hold shift1 to see frequency)
Encoder 2 = Fine-tune in cents +/- 100
Encoder 3 = Pulse width (0 - 100%)
Encoder 4 = Modifier (only applies to User and Sine wav)
OscMixer Page:
Encoder button 4 is the OscMixer.
Each of the oscillators has a volume adjustment.
Pressing the top right button will render the oscillators and send as SDS to the nth sample slot of your choice. (MD ROM slot numbers are n + 1).
@roboKob I’ve added MIDI Forward functionality. You can choose to forward Midi data from port 1 to 2 or 2 to 1.
After a bit of sysex snooping around I’ve found a whole bunch of undocumented SYSEX commands for controlling elements of the MD GUI. Entering/Exiting submenus, emulating key presses etc.
That’s very, very good!
Hoping to see them documented somewhere some day 
I wonder if such ‘snooping’ but with 
/ 
will bring some news, too. Irrationally I still have a hope that they can be commanded more fully. At the last resort, maybe Overbridge proto can be RE’d, but I digress.
Too slow.
I just posted this 
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.
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?
Yeah that’s fine. I need to remove the references to those pages before merging to master.
Edit: Just uploaded a patch for this.
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.
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.
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 ?
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.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.