OpenDeck builds MIDI and OSC devices without firmware work

The promise is a platform, not a library

OpenDeck is a platform for building interactive control and sensing devices using MIDI and OSC, and the range of hardware it targets is wide. USB MIDI DJ controllers, DAW control surfaces, Ethernet-connected OSC nodes, sensor interfaces and media installations are all named as use cases, and the main platform features follow from that list. There is browser-based configuration, so the device behaviour is described in a tool rather than in code. There is no firmware development required. The hardware is independent, meaning multiple microcontroller families and development boards are supported. There is MIDI and OSC support. And there is extensible sensor support. The framing sentence is the one to keep in mind, that the platform lets you focus on hardware and interaction design rather than tweaking and debugging firmware, which is the value proposition for someone who wants a working instrument at the end of it rather than an embedded learning curve on the way.

The configurator runs in a browser

The configurator is available either online, at the config.shanteacontrols.com address, or offline, with the OpenDeckUI releases published as a GitHub release for people who need to run it without a network connection. The README links a demo video of the configurator, and the offline route matters more than it first appears, because a tool that configures a device over a USB or network link is not much use if it needs the internet to do it. The documentation for the configurable features lives in a wiki page with a guide to everything that can be set, and the project asks people who do not find what they need to open a discussion thread rather than a feature request, which is a reasonable way to run a support channel for hardware support.

What you can wire up

The peripheral list is organised in three groups. The core input and output covers buttons, encoders, single-colour LEDs and other outputs such as relays or transistors, potentiometers, and FSRs, which are force-sensitive resistors. The display group is short, a Nextion HMI touchscreen and an SSD1306 small OLED. The sensor group is longer and more specific, with an APDS-9960 that handles proximity, light, RGB and gesture, a CAP1188 eight key capacitive touch sensor, a VL53L4CX time of flight distance sensor, a VL53L5CX with an eight by eight array, and a BNO085 nine degrees of freedom orientation and IMU fusion sensor. Every one of the sensors is marked as OSC only, which is a constraint worth noticing, since a MIDI-only board cannot use them. Each sensor also carries its own configuration options, such as smoothing and selectable event output, so the sensor is not a fixed block of behaviour.

MIDI and OSC, feature by feature

The protocol support is described in enough detail to be useful. On the MIDI side there is sending of both 7-bit and 14-bit Non-Registered Parameter Numbers, latching messages on buttons, various encoding modes for quadrature encoders, output control using MIDI In, configurable MIDI channels for each component individually, and Bluetooth MIDI. On the OSC side there is Ethernet transport, configurable destinations, sensor data streaming, output control, automatic network discovery via mDNS, and network-based configuration and firmware updates. Two of those are worth dwelling on. Configurable MIDI channels per component means a device with a knob and a pad can send on different channels and be treated as separate things by the receiving software. And network-based firmware updates mean a deployed installation can be updated without a physical visit, which is what makes an installation or a stage rig maintainable.

The official L board and what it cannot do

There is currently only one official board available to buy, the L variant, where L stands for large, and it is sold through the Lectronz store. The board is based on a Raspberry Pi RP2040 microcontroller and the specification is generous for a maker board, with 128 digital inputs, 64 digital outputs, 64 analog inputs, DIN MIDI, USB MIDI over a USB C connector, a connector for a touchscreen, a connector for an I2C OLED display, and additional connectors with 3V and 5V power and ground. The limitation is stated just as plainly. The L board does not have OSC support, because it focuses on providing a lot of I/O specifically for USB and DIN MIDI use cases, and OSC functionality is available on a number of the supported Ethernet-enabled boards instead. For a project with many inputs and outputs that does not need networking, the L board is the obvious pick, and for anything OSC it is the wrong pick.

A long board matrix

The supported boards table is the reference to check before committing, and it lists both the board and what it can do. The MIDI column distinguishes USB, DIN and BLE, and the OSC column is simply Ethernet or No. The list spans the usual maker boards, with the Adafruit Grand Central M4, the Adafruit Metro ESP32-S3, the Adafruit Metro RP2040, the Arduino Nano 33 BLE, the LILYGO T-ETH Elite, the nRF52840 and nRF5340 development kits, the Olimex ESP32-POE, the Raspberry Pi Pico and Pico 2, the ST Discovery F407VG, several ST Nucleo boards including the F767ZI, the H563ZI and the H753ZI, an STM32F411 Black Pill, the Teensy 4.0 and 4.1, the Waveshare Core405R and ESP32-S3-ETH, the W5500 and W6100 evaluation boards for the Pico, and the wESP32. Several entries achieve Ethernet by adding a W5500 or W6100 shield to a board that has USB MIDI, which is how an ESP32-S3 or an RP2040 ends up with OSC.

Zephyr underneath, with a board overlay per target

The build is Zephyr, and the repository layout shows it. There is a west.yml for the workspace, a zephyr/ directory, an app/ directory holding the application, cmake/, sch/ for the hardware designs, scripts/, tests/, an examples/ directory with an OSC example, a Makefile, and a .devcontainer/ for a reproducible development environment along with a .codechecker.yml for static analysis and an agents.md. The Makefile is short and instructive, because it includes the Zephyr environment makefile, points at a project presets file in app/presets.yml, and then derives the list of build targets by globbing the firmware overlay files under app/boards/opendeck. Each target directory holds a firmware.overlay, and the board name is parsed out of the overlay with a sed expression rather than being hardcoded, so adding a board is a matter of adding an overlay. The project ships prebuilt releases of the firmware through that same path, and the releases are v8.5.2 from 2026-08-03, v8.5.1 from 2026-06-14 and v8.5.0 from 2026-06-12, with the last push on 2026-09-23 and an Apache-2.0 licence.

Editorial conclusion

OpenDeck fits a maker or a product team building a controller, a control surface, a sensor node or an installation and who wants a working device without commissioning an embedded engineer, since the configurator and the peripheral library cover the bulk of the work. It does not fit a project that needs behaviour the configurator cannot express, because the escape hatch is writing a Zephyr application against the same tree. It does not fit an OSC-only design on the official L board, since that board has no OSC support and exists for USB and DIN MIDI use cases. Before you start, pick your board from the support matrix, check whether its MIDI and OSC columns match your design, and note the release state, with v8.5.2 published on 2026-08-03 and the last push on 2026-09-23.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. shanteacontrols/OpenDeck on GitHub