Forbidden Planet “Krell” Display – MIDI Notes

This is my first attempt at some kind of MIDI related visualisation for my Forbidden Planet “Krell” Display. I thought I’d start easy and simply map MIDI notes onto the segments and create a simple display. That turned out to be an awful lot more involved than I imagined…

In fact, this is quite sub-optimal – it largely works but does suffer still from the occasional missed MIDI message, which will almost certainly lead to stuck notes at some point.

In this post I talk through what the issue is and the various mitigations I’ve put in place to attempt to minimise the problem. Finally I present some alternative ideas that I’ll follow up in future posts.

Fundamentally, these days there are much better options for this than an Arduino Nano or Uno.

https://makertube.net/w/qwM4gzPpDSthHY1Mkutr4P

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Parts list

• Completed Forbidden Planet “Krell” Display.
• Arduino Nano or Uno.
• MIDI Interface, e.g. DIY MIDI Interfaces, Ready-Made MIDI Modules, and so on.
• Breadboard and jumper wires.

I’ve started with an Arduino Nano, but as we’ll see later, choosing a single-core, 8-bit microcontroller is certainly playing this game on “hard mode”.

I’ve written up what I have for my own interest as it is an interesting problem to solve and interesting to me to see how far I can push it, but if you’re after a more useful solution it is probably worth waiting for a later post where I can show how to use a more suitable microcontroller for this task

The Circuit

As detailed in my previous post I can just about get away with powering my 8 LED rings from the Arduino provided I keep the power levels down and don’t drive the too much.

I’ve actually used a ready-made MIDI module with a hardware MIDI THRU, again for reasons that will hopefully become clear as I talk about the performance later on.

Using THRU allows me to send data into the Arduino and use that same data to drive a sound source too.

The Code

Once again, I’m using the LED “mapping” technique from my original Forbidden Planet “Krell” Display test code, so that side of things is largely unchanged.

I’m adding in basic MIDI handling using a NoteOn and NoteOff parser to indicate that the LEDs need turning on or off. In this first version I’m just using simple logic as follows:

void handleNoteOn(byte channel, byte pitch, byte velocity) {
  if (velocity == 0) {
    // Handle this as a "note off" event
    handleNoteOff(channel, pitch, velocity);
    return;
  }

  int led = pitch - MIDI_NOTE_START;
  ledOn (led);
}

void handleNoteOff(byte channel, byte pitch, byte velocity) {
  int led = pitch - MIDI_NOTE_START;
  ledOff (led);
}

There is some bounds checking added too, but that is essentially it. The downside of this approach is that if several NoteOn messages are received, the first NoteOff message will turn the LED off even if another note is still hanging on.

By default I’ve set it to listen to all channels, but a single channel can be set at the top of the function if required, along with the range of notes to recognise.

#define MIDI_CHANNEL MIDI_CHANNEL_OMNI  // 1 to 16 or MIDI_CHANNEL_OMNI
#define MIDI_NOTE_START 48  // C3
#define MIDI_NOTE_END   MIDI_NOTE_START+39

I experimented with some simple note counting and that would work if the MIDI reception was reliable, but there is a fundamental problem with this code on an 8-bit, single-core, Arduino. The WS2812 LEDs require very precise timing and the Adafruit library has some very hand-crafted assembler running with all interrupts disabled, to achieve it. The longer the string of LEDs, the more time is spent with all interrupts disabled, and so no storing up of, for example, data received over the serial port (MIDI).

This means that I need to ensure as much MIDI handling is done as possible outside of the LED updating, and try to ensure that the actual writing to the LED strip is done as sparingly as possible.

The techniques I’m using to do this include:

• Only allowing writes to the LED strip once every 16 or more so passes through the Arduino’s loop() function, but calling MIDI handling every time (eventually I went for once every 256 scans).
• Ensure that data is only written out to the LEDs if something has actually changed. This means that the Arduino isn’t spending time updating the LED string with the same data, stopping it receiving the next set of MIDI messages.
• Run the MIDI library with Use1ByteParsing = false. This means that each call to MIDI.read() will only return either if there is no data or if the MIDI library has a complete message. Without this, a single NoteOn message requires three calls to MIDI.read() before the message is complete.
• Ensure MIDI THRU is turned off. For serial MIDI, by default, the library provides software-driven MIDI THRU handling which means processor (and serial port) time is spent sending out all MIDI data received. This can be turned off on initialisation using MIDI.turnThruOff().
• Choose an IO pin that wasn’t part of PORTD to ensure no inadvertent clashes with the UART (which is PORTD 0,1). So that means using something in the range D8-D13 (which map onto PORTB for the ATmega328). This probably makes no difference, tbh, but also doesn’t hurt either.
• Add a global inactivity timer to turn all LEDs off after any period with no MIDI activity to catch any stuck notes.

I added a timing GPIO pin to attempt to work out how much time was spent updating the LEDs. It takes just under 2mS to update the strip of 56 (7*8 – there are 7 pixels in each ring, and 8 rings, even though I’m only using 5 per ring myself). Interrupts are disabled for most of that time (from what I can see of the code in the Adafruit library’s show routine). Note, this is quite hand-wavy and the exact timings will depend on the data sent. I believe it is something like 1.2-1.3 uS per bit, so for a single 24-bit pixel (three colour values) that is ~30-35uS per pixel. For a string of 56 pixels that is around 1.7mS in total just for the data. There are some reset and rest times too, so that is where my “almost 2mS” comes from.

MIDI runs at 31250 baud, which I believe means receiving one bit over the serial port every 1/31250 or every 32 uS or so. A complete single byte in MIDI therefore takes around 320uS (there are 8 data bits, one start and one stop bit). So a typical three-byte message is just under 1mS. I don’t know for sure, but it seems like disabling all interrupts long enough to have received two complete three-byte MIDI messages doesn’t seem like a good thing to be doing…

I don’t really know much about the hardware buffer of the UART on the ATMega328 but from conversations on Mastodon (thanks Rue) and having a dig into the USART section of the datasheet, there seems to be a single character buffer, so a 2mS pause would definitely be enough time for 4 or 5 characters to be completely dropped.

This is about as far as I’ve gone using the Adafruit_NeoPixel library as is, with a single string of 40 pixels and MIDI. I have a few thoughts on where to go next, so I’ll explore those in a future post.

Find it on GitHub here.

Closing Thoughts

This works ok for relatively simple cases and is passable for more complex ones, as long as I’m after effect not accuracy

Some other things to try include:

• Splitting the string up and using different IO pins on the Arduino to drive the separate elements. A single 7-pixel ring probably takes around 300uS to update – which is comparable with the time taken to receive a single MIDI byte.
• Use a different library (e.g. FastLED) or even hard-code the updates myself (there is an excellent discussion here on how to do that).
  • Update: There is a really good description of the interrupt issue on the FastLED Gthub here: https://github.com/FastLED/FastLED/wiki/Interrupt-problems. Looks like FastLED will have the same fundamental issue and if they can’t solve it, I’m unlikely to find a better way myself
• Use a more modern microcontroller. The Raspberry Pi Pico’s PIO is perfect for things like driving WS2812 LEDs for example. Alternatively a dual-core Pico or ESP32 would allow me to split out the LED updating from the MIDI reception.
• Put a microcontroller in each display unit and string them together with MIDI IN/THRU rather than as a single LED string.

That latter option is quite tempting anyway – a Nano (or even a Micro) equivalent is pretty cheap these days. I could possibly even using something like an ATtiny. This would be an excellent approach if I built a microcontroller PCB for the displays and used those mounting posts I added to the physical design. I could keep using cheap pixel rings or really go for it and mount LEDS on the PCB.

But to be honest, for what I’m doing, I could even get away with a non-addressable LED if I’m adding a microcontroller to each unit…

Kevin

Forbidden Planet “Krell” Display

If you’re not familiar with The Forbidden Planet, then it is an iconic 1956 Sci-Fi movie with an absolutely ground-breaking soundtrack of “Electronic Tonalities” by Bebe and Louis Barron.

In one scene, when the humans visit an alien (the “Krell”) science lab there is a large set of display dials around the room that logarithmically show the power being generated by the Krell machine and I’ve been thinking for a while I’d like to try to reproduce them in a way that I could then use for something musical.

This post details the 3D and electronic design for my version of the Krell’s power indicators. The musical bit will hopefully follow at some point.

https://makertube.net/w/wmXGgm9GUeztDXn1K3nhmG

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino or 3D printing, see the Getting Started pages.

Parts list

• 3D printed Krell display unit
• Arduino Nano or Uno
• Several 7-way “neopixel”-like WS2812 5050 rings of LEDs (one per display face)
• Breadboard and jumper wires

Design and 3D Printed Case

I’ve opted to build the display in units of two or four. The original Krell setup has gauges one above the other as can be seen in this capture from the film.

I’ve designed the display in four parts as shown below (these are early versions, but you get the idea).

The required “neopixel”-like rings are also shown. I actually only need 5 LEDs per display, but I need them to map onto the 5 cut-out segments on the display. This means that the bottom and centre LEDs are not used, but the other 5 map on quite nicely to the other of the six segments in the display.

OpenSCAD Code

I’ve used OpenSCAD and the code for all parts is in a single file. This means that any definitions relating to dimensions and scale can be used by all parts. Which part gets rendered and shown is selected at the top of the code.

show_frame = 1;
show_insert = 0;
show_support = 1;
show_quadframe = 0;
show_quadsupport = 0;

The inserts are the (white) display faces, and two of these are required per twin display. They also need a frame and optionally a support (if using the LED rings).

There is also a “quad” version of the frame and support which allows for a four-way display, which naturally will then require four inserts printing.

I’ve just used standard white PLA for the inserts and that seems to diffuse the LEDs nicely once lit. The frame and supports I’ve just used black and blue PLA respectively because that was what I had to hand at the time.

Here are the key parts in OpenSCAD for the dual-display.

And these are the parts for the quad display:

The actual insert for each display panel is a pretty complex object and takes a while to render on the display when moving and zooming. And even longer to render as an STL. There is probably a better way to design this, but it works ok for me.

In terms of the OpenSCAD code, there are the following modules:

• supports() – used to build the supporting partitioning for a single face of the display. This is called twice for a twin display and four times for a quad display.
• krell() – builds the display face itself for a single display, but is also used for the cutout for the face in the main frame. Again used twice in the twin display and four times for the quad.
• krell_mark() – used to create each of the four triangles that are part of each single display face.
• pcbfixing() – used to create a pillar with a M2 sized hole that could be used to mount a PCB.
• sector() and arc() – used to build the six individual segments. It is taken from https://openhome.cc/eGossip/OpenSCAD/SectorArc.html

It’s perhaps not the most efficient, and certainly is the cause of the longer rendering times for the insert, but I’ve made quite heavy use of difference() and union() to create the various cut-outs and masked-off areas.

The face panel was particularly challenging, using combinations of spheres and cylinders. I particularly wanted the spheres to be hollow so they didn’t show up darker when illuminated from behind. Packing the spheres in also involved calculating the vertical distance using the formula: vertical position = radius * SQRT (3) and then offsetting the start of the next row by a single radius.

Design notes:

• I planned to allow for a PCB to be made and mounted in the case. This would make for a nice, self-contained unit, hence the PCB fixing points. But in the end opted for the “neopixel” style rings and jumper wires.
• The supporting partitions originally included mounting points for the M2 holes in the rings, but they proved either too small and brittle or too large. I don’t know if that was an issue that could be solved by tweaking the resolution of the print, but in the end the rings wedge in fairly well without them.
• There is little provision for wiring at the moment or for mounting a microcontroller. The units themselves are cases and LEDs rings only.
• I’ve not found any dimensions online for the displays, but from photos of props that have been sold online, I decided on the ratio 65:100 for the displays, so used that in mm for my twin display. They “feel about right” to me.

Find the source and STL files on GitHub here.

Arduino Electronic Control

I’m using an Arduino Nano but pretty much any 5V microcontroller would do. If using a 3V3 microcontroller, then level shifting would probably be required as these LED rings really do nee 5V for power and signals.

The LED rings are collections of WS2812 or compatible 5050 (i.e. 5mm square) multi-colour addressable LEDs. Adafruit call these “NeoPixels” and have a very comprehensive guide for using them here: https://learn.adafruit.com/adafruit-neopixel-uberguide

The rings that I have, have two sets of three solder pads on the rear. Both sets have VCC and GND, but one is a signal IN and one is a signal OUT. This allows them to be chained together as shown above. Two rings are required for a single dual-face unit. Some rings might have pads, holes or even connectors.

The Adafruit Uberguide talks in detail about powering these rings, especially when used in long strings for large displays. As a general rule, the recommendation is to allow for 20mA per “pixel” up to a maximum of 60mA for full brightness with all LEDS on per “pixel”.

As the Arduino can support up to 800mA via its 5V pin and I’m planning on using 8 display faces, each with 5 LEDs per face, that gives an estimate of:

• 8 x 5 x 20mA = 800 mA as a typical draw.
• 8 x 5 x 60mA = 2.4A peak for full brightness, all LEDs.

I think I can just about get away with driving my 8 faces from a Nano as long as I’m not expecting to turn everything on at full brightness – more on that in a moment when I get to the example code.

If I wanted to support something nearer the peak current I would need a separate power supply providing 5V and around 2A to the LEDs. That could probably be wired to provide a 5V link directly into the Arduino’s 5V pin too. However, this is not recommended though due to the potential for mistakes, noisy signals, and interrupts in supply, as this bypasses the regulator and any protection circuits on the Arduino.

But if I’m careful, it will be fine as an option for me if I need it.

The Code

Driving WS2812 LEDs is pretty straight forward thanks to the Adafruit_NeoPixel library for Arduino which is easily installed via the Library Manager.

One complication I have is that I need to translate between the order and number of LEDs on the rings and the 5 LEDs per ring I want to be using.

The ordering of my LEDs is as follows:

But that might be different for different rings of course. The following code is a simple test to illuminate each LED in turn allowing me to find the order, and shows all the key principles of how to turn the pixels on or off:

#include <Adafruit_NeoPixel.h>

#define LED_PIN   6
#define LED_COUNT 14

Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);

void clearStrip () {
  for(int i=0; i<strip.numPixels(); i++) {
    strip.setPixelColor(i, strip.Color(0, 0, 0));
  }
}

void setup() {
  strip.begin();
  strip.show();
  strip.setBrightness(50);
}

void loop() {
  for(int i=0; i<strip.numPixels(); i++) {
    clearStrip();
    strip.setPixelColor(i, strip.Color(80, 35, 0));
    strip.show();
    delay(500);
  }
}

The definitions used in the Adafruit_NeoPixel initialisation (NEO_GRB+NEO_KHZ800) work for my rings, but there are several options. Try some of the library examples and consult the Uberguide for details if the rings aren’t working.

In order to map this order over to just the LEDs I need to use for my Krell display, I need two “lists” of LEDs – the real one representing the physical order the 7 LEDs per ring appear on the rings themselves, especially when linked together; and a virtual one representing the desired order of the 5 LEDs per ring I’m interested in using.

I do that via the following definitions and code:

#define LED_PIN   6
#define LED_BLOCK 5
#define LED_RINGS 8
#define LED_COUNT (LED_BLOCK*LED_RINGS)
#define STRIP_BLOCK 7
#define STRIP_COUNT (LED_RINGS*STRIP_BLOCK)

int ledpattern[LED_BLOCK] = {1,0,5,4,3};
int leds[LED_COUNT];

void setup() {
  for (int i=0; i<LED_RINGS; i++) {
    for (int j=0; j<LED_BLOCK; j++) {
      leds[LED_BLOCK*i + j] = ledpattern[j] + STRIP_BLOCK*i;
    }
  }
  ...
}

The ledpattern[] array lists which physical LED corresponds to my five virtual LEDs. The leds[] array will expand this list to the number of rings, giving offsets for all physical LEDs used to map onto all my virtual LEDs.

In order to allow this to be changed to match the number of rings used, simply by changing the #defines at the top of the code, leds[] is initialised in code as part of setup(). For two rings in a twin display, this maps virtual LEDS 0 to 9 onto real LEDS 0 to 13, with four of them being unused. For four rings in a quad display, this will map 0 to 19 onto 0 to 27, and so on.

In order to use this with the Adafruit functions, I just take my virtual LED number and use that as an index into leds[] to get the real LED number, for example:

  for(int i=0; i<LED_COUNT; i++) {
    clearStrip();
    strip.setPixelColor(leds[i], strip.Color(80, 35, 0));
    strip.show();
    delay(200);
  }

I have some example code to test all LEDs. The simple version just illuminates each LED in turn, using the above code. An alternative version will read a potentiometer and use that to determine how many LEDs to illuminate.

With the correct wiring sequence and pattern of LEDs it is possible to mimic the order of the illumination of the panels in the original film.

A note on colour, brightness and power.

As previously discussed, I’m working on the basis that not all LEDs will be on at full brightness and so can get away with powering my display simply from an Arduino. For this to be true, I’m working with the following constraints:

• No more than 8 rings are used. In my case that is two dual displays and one quad display.
• Not all LEDs are used for the colours. I’m using: strip.Color(80, 35, 0) which leaves on LED of each of the three in each pixel off and gives a nice, nostalgic, colouring which to my mind matches that used in the film quite well.
• Brightness is set relatively low, using: strip.setBrightness(50), which is less than a quarter brightness (the maximum is 255).

Find the test code on GitHub here.

Closing Thoughts

I’m really pleased with how this has turned out. It took a little trial and error to get the parts to fit and work, but the colouring through the white PLA is quite pleasing to me. The partitions also work well to allow individual control of the segments without the light bleeding through.

The simple code with a potentiometer control shows the potential. I have a few ideas for how to use this with MIDI, but those can come in a future post.

Kevin