History

Developer Manual -> Library Reference -> GUI

GUI

Introduction

The interface of the MiniCommand (or of any hardware MIDI controller, for that matter, is quite different from a GUI
on a computer. Instead of having one or two input devices (the mouse and the keyboard), the developer is suddenly
confronted by a multitude of input devices. In the case of the MiniCommand, you have to handle 4 encoders,
4 buttons, and a screen that is very different than a normal computer screen: a 2x16 character LCD.

To make matters worse, the microcontroller in the MiniCommand is not fast or big enough to run a real operating
systems. There are no device drivers that interface to the hardware in an "abstract" and "clean" way. Instead, the
polling of the encoders, of the buttons and writing to the screen has a definite impact on performance and is
deeply interwoven with the normal run loop of the running software. To read the encoders (which are just buttons as well
and the buttons, they have to be polled at regular intervals and the results analyzed. In a similar fashion, writing
to the screen is not done through a framebuffer, but by sending commands to the display controller, which takes
time, and can't happen everywhere in the runloop.

To make it easier for the MiniCommand developer, the MIDI-CTRL provides a complete GUI abstraction that makes
it much easier to handle all these constraints.

GUI modules

The GUI library is built out of a main static object called GUI, which provides a host of functions to interface with the
LCD. It is described in The GUI class.

Events

Button presses are handled through an eventHandler function, which is described in Handling events

Encoders

The hardware encoders are made available through "virtual" encoders, implemented by The Encoder class. The
currently active virtual encoders are updated by the hardware encoders when these are moved. That way, the code
actually doing something useful (like sending CC values, or updating control parameters) is independent from
handling the hardware. The Encoder class comes with a lot of useful subclasses, like CCEncoder (which sends CC
values automatically), MDEncoder (which updates parameters on the MachineDrum), MDFXEncoder (which modifies
global effect parameters on the MachineDrum), EnumEncoder (to choose between different options), BoolEncoder
(to set a value to ON or OFF), NotePitchEncoder (to select a MIDI pitch).

Pages

Virtual encoders and event handling functions can be grouped into so-called Pages, described in The Page class.
Pages are the MiniCommand equivalent of "windows" on a normal computer GUI. They group encoders, handle
the displaying and updating automatically, and allow to create self-contained GUI screens. For example, the MIDI
clock setup menu is a page, the AutoMagic learn page in the LivePatch sketches are a page, all the configuration
screens for the arpeggiator or the euclid firmwares are pages. In MIDI-CTRL, everything that the user sees is
usually a page.

Sketches

Going further, Pages can be grouped into a Sketch, described in The Sketch class. Sketches are basically
self-contained programs, and are made of multiple Pages, as well as a Sketch event handler. Sketches often provide
a way to switch between different Pages, usually through another SwitchPage. The GUI object contains a pointer
to the currently active Sketch, and defers all the GUI events to it.

Tasks

Finally, the GUI also provides a way to run regular tasks. For example, on the MachineDrum and MonoMachine
firmwares, there is a task polling the synthesizer to ask which kit is currently active, which pattern is currently
playing, and which global settings are currently used. The Tasks are described in GUI Tasks.

Also available in: HTML TXT