DelugeFirmware: open firmware for the Synthstrom Audible Deluge

Why the firmware exists at all

The Deluge from Synthstrom Audible is a portable sequencer, synthesizer and sampler. What makes this repository unusual is the second paragraph of the README: Synthstrom Audible decided to open source the firmware application that runs on the Deluge so that the community could customize and extend the capabilities of the device.

That distinction matters. Open sourcing a device's firmware application does not mean the manufacturer hands over a new product line and walks away; it means the application layer is available for people to change while the hardware stays what it is. The result is the community firmware you are reading about, which is what the README calls the Deluge Community Firmware.

The README opens with a note addressed to Deluge owners, and it is a redirect rather than an explanation. If you want to start using the community firmware, the page to visit is delugecommunity.com, and that is where the relevant details live. The repository's own README is deliberately short: it explains what the hardware is, points at the community site, and points at the documentation you need for each task.

The links are organised by what you want to do. Acquiring and using the firmware goes to the community website. Installing it goes to the update guide in the project wiki. Contributing code, bug reports and suggestions goes to a contributing document in the docs directory of this repository. Learning the toolchain and application and starting on the code goes to a getting started page on the community site, and there are also links to the Synthstrom forum and a community Discord.

The homepage is the community site, the licence is GPL-3.0 with a LICENSE file at the root, and the recent releases are v1.3.0-rc2 from 2026-10-19, a beta release tagged with that day's date, and release_1_2_1 from 2025-05-12 named for a release called Chopin. The last push was on 2026-10-19 and the project is not archived.

Bare metal on a Cortex-A9, with no operating system underneath

The hardware description in the README is the part that tells you what kind of engineering this is.

The Deluge is built around a Renesas RZ/A1L processor with an Arm Cortex-A9 core running at 400MHz and 3MB of on-chip SRAM. Connected to that is a 64MB SDRAM chip, a PIC for button handling, and either a 7-Segment array or an OLED screen. The application is written in C and C++ with some occasional assembly in bare metal style, without an operating system.

Bare metal is the phrase to hold onto. There is no Linux, no RTOS and no process model underneath the application, so every line is either hardware access or application logic. The RAM budget is the constraint that shapes the whole design: 3MB on chip plus 64MB of SDRAM is not much for a sampler that is expected to hold audio in memory, and it is the reason the code is written the way it is.

The two display options are worth noting because they are a hardware fork, not a software preference. A 7-Segment array and an OLED are different displays with different capabilities, and the firmware has to support both. The PIC handling buttons is another piece of the design that is unusual outside embedded audio gear: the main processor and the button handling are separate chips, which means there is a communication path between them that the application code has to account for.

The primary language of the repository is C++, and the topic list covers audio, baremetal, dsp and firmware. All four are visible in the tree: a src/ directory for the application, a lib/ directory for library code, a toolchain/ directory, a linker_script_rz_a1l.ld file at the root named for the processor family, and tests/.

dbt sits above CMake, and the Makefile is a thin wrapper

The build system is layered, and the layering is visible in the repository root.

At the bottom is a CMakeLists.txt, which is what bare metal C++ projects usually use for the compile graph, the compiler flags and the link step against that processor-specific linker script. The root also carries toolchain/ files, which is where the cross-compilation toolchain configuration lives, since building for a Cortex-A9 means using a specific GCC target rather than your host compiler.

Above CMake sits dbt, a Python-driven build tool, present in the repository as dbt.py, with a dbt.cmd wrapper for Windows and a dbt shell entry point. The Makefile at the root is a thin wrapper over it, and reading it explains the structure:

all: debug release

debug:
	$(DBT) build debug

release:
	$(DBT) build release

clean:
	$(DBT) clean

The one conditional at the top of the Makefile selects which dbt entry point to use, and it is the only place the platform difference appears, because the Windows check is on the OS environment variable and everything else is the same command:

ifeq ($(OS),Windows_NT)
		export DBT := cmd.exe /c dbt.cmd
else
		export DBT := ./dbt
endif

The all target builds both a debug and a release configuration, and there are separate debug, release and clean targets underneath.

What is notable is that a Python tool drives the build. In a project of this kind that is not a convenience, it is a necessity of the same order as the toolchain file: generating build variants, managing the dependency set, and giving one command for the things contributors actually need are all easier to express in a scripting language than in a build system of the C++ variety, which is the same reasoning behind the dbt.cmd and dbt pairing.

The toolchain is the real entry point for contributors

The README's guidance for anyone who wants to work on the code is to continue with the Getting Started with Deluge Development page on the community site, and to learn about the toolchain, the application, and to start working on the code there.

That is an honest division of responsibility. A bare metal firmware repository is not usable without knowing how the toolchain is set up, and that setup is long, version-specific and exactly the kind of knowledge that goes stale in a README. Keeping it on a site that can be updated independently of the code is a reasonable arrangement.

The repository itself carries the pieces that a developer needs day to day, and they form a telling list. There are IDE_Configs/ directories, so the project is expected to be worked on in an IDE, and there is a .clangd file, which is the configuration file for the clangd language server. There is a .clang-format and a .clang-format-ignore, so formatting is enforced by a tool rather than by convention, and a .clang-tidy, so the static analysis checks are part of the normal workflow.

There is also a .pre-commit-config.yaml, which means the formatting and lint checks run on commits rather than only in CI, and a .editorconfig for the whitespace rules that keep a mixed-toolchain project consistent. The .git-blame-ignore-revs file is the kind of thing a project adds after a reformat that would otherwise make the history unreadable, and CODEOWNERS records who reviews which area.

A scripts/ directory, a contrib/ directory, a website/ directory for the documentation site, a dbt directory for the build tool's own code, a tests/ directory and an assets/ directory complete the picture. The CHANGELOG.md at the root is where a user-facing change would be recorded.

The result is a project that looks like it is set up for outside contributors rather than only for a small internal team, which is the practical test of whether an open sourcing effort has worked.

What the community firmware is for, and who should install it

The Deluge is a hardware instrument, and the reason to install community firmware is specific: you want behaviour the shipping application does not provide, or you want a fix that the vendor has not shipped, or you want to change the behaviour yourself.

The community site is where those additions are documented, and it is the entry point the README gives to every owner who wants to start. The update guide in the wiki is the second document, and it covers the practical mechanics of installing firmware, which is the step that actually carries risk. Flashing firmware to a device is a one-way-ish operation: the device runs the new software, and if the new software does not behave, you need a way back.

The release naming tells you the state of the project. The newest tagged artefact is v1.3.0-rc2, a release candidate, which is a conventional signal that the version is close but not finished. Alongside it is a tag called beta with a date-based name, which is a rolling tag for the current development build, and before that sits release_1_2_1 from 2025-05-12 with the name Chopin, following the musical naming scheme the project uses for its releases.

The two different kinds of artefact therefore answer two different questions. The release candidate is what you would install if you want a named version. The beta tag tracks the tip of main, which is where the newest work is, and which is also where regressions show up first.

The community is organised around the delugecommunity.com site, with a Discord and the vendor's own forum as the places where users and developers meet. The Synthstrom Patreon is the donation route. And the hardware vendor still exists and still makes the device, which is the clearest statement of what this repository is: an open application layer on closed hardware, maintained by the people who own it.

Editorial conclusion

Adopt DelugeFirmware if you own a Deluge and want features the shipping application does not have, or if you want to fix a bug on hardware you can hold in your hands, and if you are willing to flash firmware and keep a recovery path in mind. Do not adopt it if you need a stable vendor-supported product, because a release candidate is the newest tagged artefact and the community firmware is maintained by volunteers rather than the hardware maker. Before you commit, read the update guide in the project wiki, work through the Getting Started with Deluge Development page for the toolchain, and check the release tags, since v1.3.0-rc2 and the beta tag are what you would actually be installing rather than the 1.2.1 release from 2025.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. SynthstromAudible/DelugeFirmware on GitHub