Designing Mimetic Digitwolis, part 2

Earlier this month, we introduced Mimetic Digitwolis, the sequel to our classic Mimetic Digitalis step sequencer. Last week, we talked about the design process we went through when creating the hardware. Today, we’ll be pulling back the curtain on the (somewhat grueling) process of developing and testing the firmware.

MD2’s firmware is much more complex than the original, with over 8,000 lines of code. Before we get behind the scenes and look at the process of developing Mimetic Digitwolis’s extensive firmware, we decided to release the source code for the original Mimetic Digitalis. If you’re curious about what the original module’s (much simpler) code looked like, you can check it out here.

First steps and initial design

Whenever we get a new piece of hardware, we start a barebones firmware design to get the interface working to make sure all the bits work. Since MD2 features a screen, it took some time to get it to do anything, especially since it was our first time putting a color screen on a product, and any screen on this processor. 

Mimetic Digitwolis with static on its screen
Some display is better than no display, right?

After Kris designs the hardware and makes any necessary changes to the prototype, the module generally disappears into Stephen’s office for a while. After a few days, we were excited to see that progress had been made, and the boot screen was functioning as designed.
Mimetic Digitwolis with a rainbow on its screen and the firmware number 00000

The first rainbow was an exciting moment for all of us.

Stephen started by recreating some of the basic functionality of the original, and implementing a few ideas that we knew we needed: a menu system, a way to change input mapping, and the fancy new pitch lane option. 
Mimetic Digitwolis with a note lane on screen

The first look at the all-new pitch lane prototype. 

At this point, we started throwing ideas at the board for what we wanted the module to do. It turned out that the answer to that was a lot. 

Core functionality vs. feature creep: FIGHT

One of the ongoing challenges of firmware development was refining what would be useful functionality versus feature creep. Since the interface was so flexible with its screen and routable I/O, we could conceivably do anything relating to CV generation. We did have two limits: the maximum size of the firmware and save data had to fit on the module’s storage (a hard limit), and we needed to make sure the module wasn’t so complex it stopped being fun and immediate (a more nebulous limit).

Early on, we decided that we never wanted menus to be more than two layers deep, with no more than 6 items per menu. This helped limit the number of possibilities – there was enough room within these constraints to do everything the module needed to do, without endless scrolling and deep dives to find settings. [note from Kris: I lost some fights over things I wanted in because they would have been the 7th thing in the menu.]

There were still quite a few things that we considered doing and decided to cut out. The Quantizer lane type, for example, was almost cut a number of times, since it was somewhat outside of the scope of the original module. We decided to keep it since it was so useful, and shared so much of the interface with Note lanes.

New features were proposed, added, tested, and occasionally removed until about a week before the final firmware was finished. We keep a running list of potential features that we want to consider for future development, too. 

The process of testing Mimetic Digitwolis

For early development, Markus and Stephen usually go back and forth fixing the nitty-gritty before the rest of the team gets involved. For MD2, this was quite the process – in the past few years, Univer Inter and Xer Mixa were complex endeavors, but Mimetic Digitwolis won out as the most complex test project due to its immense configurability. 

Initial test started out with verifying that basic functionality worked. (Can we actually reassign inputs? Does pitch CV respect the scale? Do clocks respond correctly?) We also set our performance parameters at this point, since, for a sequencer, latency is of the utmost importance. Throughout all of the test process (up to the date the release firmware was set) minor bugs were discovered and squashed. In the early days, bugs tend to be pretty obvious (trig lane with length==1 doesn't output triggers”), but become increasingly subtle and obscure (tapped encoder to edit lane 1: quantizer slew, then tapped 2: cv without deselecting the slew field. rotating the encoder opens the Presets menu”). [note from Kris: this is really how Markus tests. We would be lost without them.]

After the basics were sorted out, workflow was the next big challenge. The entire menu system was redesigned and reorganized twice, with smaller tweaks being made as components were removed and added to make the system cohesive. We don’t like adding menus to things when we can avoid it, so we want the menus we do have to be as simple to use as possible. At this point, we started sneaking out some test footage to our Discord community, since we were excited and wanted to share what we’d been working on.
A Discord chatroom screenshot, where Markus shared a video of a test patch
About two weeks before the firmware deadline, we were spending all development time on finishing the firmware. This was both an exciting time, as we got the whole team involved, and a frustrating time, as we were working on the most obscure bugs.
Stephen: Wait, so you can quick load a save with midi transport, just not load load a save with midi transport? Markus: correct. Stephen: there are not enough cuss words

Testing is always a headache-inducing experience.  

Once we had a nearly finished firmware, we began real-world tests by putting them into our actual systems. This is always the most fun (and occasionally most frustrating) part of test, as we get to see what the module can really do (and find any lingering issues that need to be resolved). Stephen stuck a pair of MD2s in his performance system, and you can hear some of his early tests as performances on our YouTube channel. 
With the module working well and all features in a good spot, we were ready to finalize the release firmware. As with all of our high-complexity firmware-based products, Markus developed a release checklist during the test process for the final firmware. This checklist, with 136 items for MD2, checks that all features are working as expected, avoiding regressions in basic features as well as performance.

The Bug List 

During test, Markus and Stephen kept a running list of all bugs as they were fixed. If you want an inside look at the strenuous, if humorous, process of bug fixing the firmware for MD2, you can check it out below. Did we catch everything?  Maybe not. This list gives you an insight to the level at which we were testing. Find something you think isn’t quite right? Drop us a line and let us know! 

Verified

====

* quantizer MIDI output doesn't respect scale selection 

* xport mode: gate always advances lanes at the same rate no matter the xport setting

* all presets have MIDI set to Advanc if a lane is set to note (or changed from another output type to note)

* I sometimes get an orange remnant of the select indicator around pitch lanes

* lane 1: quantizer, lane 2: CV. tapped encoder to edit lane 1 slew, then tapped 2 without deselecting the slew field. rotating the encoder opens the Presets menu

* manually loading slot M then slot A while a MIDI clock is going in and slot A has MIDI clock transport enabled causes slot A's sequence data to load incorrectly; quick loading slot a works correctly

* qtiz lane type is constrained to the same output range as note lane type with no way to change output range

* changing note length via shortcut on overview screen in edit mode resulted in lines being left over 

* prev+next doesn't jump to step 1 in edit mode (should not affect play cursor) 

* if you set a note lane to <=5 steps and then go into edit mode on the overview screen there's no indication of what step is being edited

    * neither edit nor play cursors were ever rendering right in any note overview 

* start in reset mode 

* exclude the following global settings from load/save

  * note letter/number

  * ScrS On/Off

  * MIDI Chan

  * Thru On/Off

* more save slots

* focus view: quick save takes you to the pressed lane

* if you turn up a CV MIDI: CC value above 99 it loops to display 0 but actually outputs on CC 100

* gate/trig lane MIDI out seems to just output a note on,note off every time there's an advance instead of outputting the actual gate sequence

* turning up slew on a CV, qtiz, or pitch lane decreases the maximum output level

* pressing Zero in note mode ignores note minimum and always goes to 0v

* 5V step offset goes to step 15 instead of 16

* 4x4 preset: lanes are set to 16x1

* with lanes <16 steps the orange selector box still appears even if the lane isn't selected in the overview screen

* make level meter and step meter match on overview screen

* if the level bar on the focus screen is at max and it autosaves, part of the R remains

* global MIDI channel? (using channel for lane 1 right now)

* global MIDI menu is "Midi", channel MIDI menus are "MIDI"

* doesn't send MIDI program changes

* CV scaling: a 5v input only takes the output to 4.6

* voltages slightly below 1v always recorded/quantized to B

* Move qtize output menu to inputs

* CV scaling: a 5v input only takes the output to 4.6

* No trigger output menu

* Move qtize output menu to inputs

* voltages slightly below 1v always recorded/quantized to B

* 5v CV into step offset only takes me to step 15 instead of step 16

* transport reset may not be clearing dividers correctly (lane 4 advanced by lane 1 (trig), lane 4 has div, switch stop/start is out of phase)

* note mode output offset: i can dial in a noisy output between notes

* move CV hyst into hui (retest all CV inputs for noise)

* CV mode output scale or noise: getting some noise on both

* make quantizer MIDI out respect gate length

* if you power off while the autosave indicator is on the screen it loses the calibration

* loading a note lane out of a CV lane from the screensaver sometimes messes with the top of the screen

* doesn't receive MIDI program changes

* quantize view should include offset

* output scale goes to max when input voltage is around 2.4v

* lanes still respond to CV address when Stop is active

* output scl seems to be broken for all output types

* stop should reset when you exit stop, not when you ente

* Lots of systematic save stuff so test everything save

* set lane to qtize, load settings that dont have qtize lane, gui crap is bad.. (load should do a fulls screen clear)

* quantize input mapping and CV/note record input mapping are shared, which is inconvenient when you swap between modes

* calibration data is saved to external flash and will survive a firmware update

* lane config: type: CV displays in top right corner as "Cv" not "CV"

* menu selects should also dim when something is being edited

* lane config: type: CV displays in top right corner as Note and type: trig displays as Gate

* ability to use a trigger lane as an internal trigger source

* save/load buttons don't open respective menus if you make a ramp

* bpm should go below 60 (maybe 30?)

* trig lane with length==1 doesn't output triggers

* internal clock

* "stop" should reset; does not

* pressing "save" while in "load" menu doesn't go to save menu (and vice versa)

* if you're on the lane focus screen, press "save", then "esc", it takes you to the overview screen

* Copy+encoder turn on a note track only works to expand, can't make the range smaller

* quantize zoom view is weirdly centered on y

* no save indicator on lane view

* pressing prev+next activates the reset state instead of jumping to step 1; i'd much prefer it to just jump to step 1 so you don't have to press a button again

* trigger/gate MIDI note option should be a letter instead of a number

* pressing shred before load in a load+shred opens load screen **i found a few more related issues eg load_zero, maybe try to find any i missed?**

* verify encoder DNI simplification (encoder should not be flakey)

* in note mode, when an up/down is created the highest note is 0v instead of 5v or whatever

* in note mode, ramp makes a ramp shape, but doesn't constrain to the minimum/maximum settings

* weekend: on the screen it looks like CV is advancing steps correctly, but it doesn't change the output value to reflect the current step

* feels like the hysteresis window isn't big enough on step interpolation when CV addressing

* implement presets

* from step 1, CVing 0v to +5v takes you to the last step, but just over 5v it starts to jump between first and last step

* No debounce caps (need software testing / support) *PASS* (need markus test)

* MIDI Out

  * CCs on CV

  * Note On/Off on note

* MIDI Scale Select (quantize mode)

  * hold,timeout,toggle

* highlight source lane when copying lanes

* quantize should advance blink when value is read

* CV shred, switch to note, output not qtiz

* Ability to display notes as numbers

* Save Menu functioning

* Load Menu functioning

* save through menu them loading that save ends up with user in save menu (Should be overview)

* first quick save doesnt work (works on second press)

* setting note max to max note note select will cycle through to the bottom note

* qtiz config MIDI has CC (should have note mode) (all lane types should have mostly appropriate looking menus now, only cc modes work)

Explore More: