Deluge Community | Blog

Embedded Foundations

Sun, 08 Nov 2026 00:00:00 GMT

Hi everyone, I’m Katherine Whitlock, one of the core maintainers of the Deluge’s Community Firmware alongside Mark and Sean. For the last six to eight months I’ve been working on a branch internally called next, which is planned to be the second major release (i.e. 2.x). As we get closer to releasing it, currently planned for the end of January, I thought it might be worth doing a set of blog posts on what the major changes are and why they’re being done. These include, but are not limited to, topics like:

HALs and BSPs (this post)
Testing and development strategies for the Deluge
File reading, writing, and streaming (async vs synchronous I/O and cache coherence)
Multi-tasking and scheduling for music devices
Atomic model state and data flow
Embedded UI architecture
Soft real-time render loops
Compile-time composable SIMD DSP components and other optimization strategies
The Deluge’s synth architecture

And many other things!

So without further ado, here’s the first entry in the series:

Embedded Foundations

Have you ever looked at a synthesizer or sampler or Eurorack module and wondered, “Wow, there’s a lot of stuff going on there. How does it know what I’m doing and how I’m interacting with it?” If so, then you’re in luck. If not, then maybe this will give some insight anyway, so that in the future you’ll know how this all works.

In modern embedded devices, such as synthesizers, samplers, keyboards, controllers, Eurorack modules, etc., it’s very rare that whatever does all the audio processing is written so specifically for a processor that it’s manually poking all the memory addresses and registers to communicate with all the buttons, switches, knobs, and screens that may exist.

Instead, this is often left to a dedicated platform layer, allowing some level of abstraction between whatever runtime or application code may exist and the hardware itself. This increases portability and ease of development, while also allowing for better separation of concerns.

For example, many devices and products run on the Arduino framework. This framework is responsible for knowing details of both the CPU and (to some degree) the board, and then presenting an easy-to-use facade over top which allows fairly easy portability between various Arduino boards. It is a relatively simple endeavor to port a program written for an older Uno R3 to a Mega or even an Adafruit Metro.

The same line of code can be used across multiple boards. The framework knows how pin names map to specific port/pin combos for a given CPU and board.

How things work today

On the Deluge, this layer originally started out as Renesas’ own vendor platform code and drivers (Renesas being the manufacturer of the Deluge’s CPU, the RZ/A1L), and became entangled with the application code as it was further developed. This is evident in the way that both the RZ/A1L platform code and the application call into each other, and the way that the application does things such as reading raw bytes from the PIC or interacting with the SD routine.

Essentially, the Deluge is married to its hardware by virtue of this entanglement, and in order to get it running on anything else (such as x86 or ARM64), this had to be remedied.

The solution to this was to start from scratch: an entirely new set of layers, written in Rust for safety, running on top of the Embassy runtime framework, and abstracting away all the platform details and drivers that an application shouldn’t need to know to run.

Ultimately this required recreating most of Renesas’ drivers, and even writing new ones, that were up to spec and matched what we needed.

How old drivers map to implementations and crates in the new stack, as well as the libdeluge boundary used to enforce this.

HALs and BSPs

A “HAL” or “Hardware Abstraction Layer” acts as the first real layer between an application and silicon. It’s typically intended for a single CPU model or a CPU family, and has details about which memory locations correspond to different peripherals. In the case of Rust, it also acts as a safety barrier, presenting a safe “owning” API that works in conjunction with Rust’s borrow checker to hide the messy unsafe details of poking raw registers and memory locations.

A “BSP” or “Board Support Package” is exactly what it says on the tin: if the HAL abstracts details of a CPU, then the BSP does the same for an entire board. This includes things like drivers for whatever I2C, SPI, and UART devices may be connected to the CPU, and also simplifications for interacting with them. This is also where a lot of aliasing and binding happens, so that instead of saying “turn on the LED on pin 13 in inverted mode”, you can instead say “turn on the SYNC LED”.

Together, these two layers act as a way to hide details inside them. Previously, if you pressed a button on the Deluge, the application would read raw bytes directly from the UART peripheral, queue up events and handle the appropriate response itself before sending out raw color bytes. Now that behavior has moved below the platform boundary.

So now, the HAL is responsible for receiving the UART data into a DMA ring, and the BSP is responsible for decoding it and simply presenting the application with a queue of events saying “hey, this is what’s happened since you last checked.” And the application can go “neat, I need these things to change” and the BSP will properly convert those outgoing commands to the hardware-specific operations that need to be performed.

A single pad press and its LED response. On the current firmware, the app handles raw bytes. On next, it receives a pad event and sends pad colors, while the layer below is actually responsible for the hardware-specific translation and messaging.

This is not a Rust rewrite

Some may see this as the beginning of a full-stack Rust rewrite. While that may occur in the long term, it’s orthogonal to the problem this is solving. Instead, it’s simply that Rust is the best solution to this particular problem, due to both its language architecture and the Embassy framework (which will be discussed in a subsequent blog post). Rust is very useful for the kind of safety-critical code that should exist below this boundary, such as an allocator and platform-specific cache management.

In addition to this, Embassy gives us a lot of extra stuff “for free” if we implement the HAL and BSP correctly. Things like USB support for both host and device, interrupt-based task scheduling, etc. This is all extremely valuable for a (soft) real-time instrument, and means that we don’t have to maintain as much code ourselves.

The Deluge application itself is, and remains, C++ due to the advantages that gives us and our limited time.

The boundary: libdeluge

Both Rust and C++ (as well as many other languages) interface very well with C. Because of this, we can use C as a way to “translate” between the two layers, creating a contract that both must follow in order to work properly. In programmer terms, this is called an “ABI boundary”.

There are now a number of C headers that act as that contract, and, even better, by using Rust macros we can enforce the type safety of this boundary, so that mistakes can’t catch us out. (You can still make mistakes relating to execution context and threading, but those are much more subtle issues.)

How this contract catches a mistake: introducing a u32 where a u16 is expected causes the Rust binding system to emit a compile-time error rather than silently continue.

In-place replacement

The retirement timeline, over four months.

The first step to migrating all of this was to look at the existing boundary, and begin routing both the Renesas C platform code and the C++ application calls through new C headers.

Following the convention that platform code is typically provided as a library, I decided to call this platform layer “libdeluge”.

Rather than just flipping the switch over to Rust one day, this was a multi-week process of migrating the Renesas functions into a new C/C++ static library behind the libdeluge interface, so that there was a proper record and understanding of all the ABI functions we needed to fill.

Once that was done, there were a few more weeks of untangling the ABI to have (mostly) unidirectional calling conventions, and mapping out how to best wire in both the Rust BSP and the other major benefit of doing all this: a new hosted (x86/A64) platform layer.

For a long time, all three existed independently, until more and more pieces moved below the ABI boundary (such as the filesystem access and task scheduling), and the original Renesas code was no longer needed.

How things changed beneath libdeluge over the migration.

The end goal

To be brief, doing all this allows us to run the Deluge’s application code almost anywhere, including on our own computers. Instead of having to rely on slow architectural emulators like QEMU or Unicorn, we had a hosted platform implementation very early on. This speeds up testing considerably, as things like rendering songs and checking hashes can happen in seconds instead of minutes.

Once the Rust/Embassy side was introduced and things were migrated onto it, Embassy itself offers a hosted build and executor, meaning the C hosted libdeluge implementation was quickly retired and stopped being a maintenance burden whenever the ABI changed.

Because of this, we now have ./dbt sim, which is the Deluge running natively on your computer for simulation, and much more complex testing harnesses for integration testing.

How the application is shared and reused between multiple platforms without modification other than new platform library linking.

What’s left?

This was just step one: the groundwork that made a rigorous and repeatable testing harness possible.

Our next post will take a look at exactly that, detailing how work is being done while ensuring that the Deluge’s behavior doesn’t change unexpectedly.

If you’d like to use the HAL and BSP for your own projects, they’re available as part of the Deluge SDK, which is currently in Developer Preview. The SDK will get a blog post/announcement when it’s fully released in its own right.

Built Together: Community and the Deluge Firmware

Mon, 26 Oct 2026 00:00:00 GMT

The Deluge is a strange and wonderful instrument. It’s a sequencer, a sampler, a synth, a groovebox, or a looper, or a drum machine, or a sequencer, or whatever you want it to be, and it fits in a bag. The firmware that runs it exists because a lot of people care about it, and that was true long before any of us were using AI tools to write code.

I want to talk about a couple things: how we’ve been using AI while working on the firmware, and why it hasn’t changed the need for community

We love contributions

I’ve seen a handful of comments around that we’re letting our egos drive the deluge development and refusing to use AI or accept AI PRs. I want to reassure everyone that couldn’t be further from the truth - we are all embracing AI as much as it can help the firmware. My day job is in AI research. We’re not luddites or trying to stick our head in the sand and pretend it’ll go away (as much as I wish it could).

Nor are we refusing PRs on principle - 80+ people have directly contributed to the deluge code. Many of them have used LLMs and have little to no development experience. Our guiding principle is that you should be able to articulate why a change is a good idea in your own words and not use an LLM to communicate with us. This isn’t meant to be a judgement on anyone. We’re not expecting people to have performance worked out from the get go, or a perfect UI. We are expecting the ability to talk about the change, discuss whether it’s a good idea, weigh the pros and cons, and work with us to get it merged into the firmware.

None of my favourite features are things that I’ve coded

It’s a bit like asking me to pick my favourite student. Of course I have one but I’ll never admit it. That said some of the ones I’d like to highlight as we get closer to the 1.3 release are:

The new generative arpeggiator courtesy of Raúl Muñoz. I use this all the time, it’s the background music of my life
The completely overhauled UI started by Nikodemus Siivola, continued by Leonid Burygin, featuring a new delugey small font design from Casey Tucker with input from Reza Iman
Tempo automation from Michael Mackus. I did the backend work on this forever ago but he finally did all the hard UI work to make it usable :)
The chord keyboard from Madeline Scyphers
This website from mgabor (real name unknown but hopefully he’ll find this and I’ll update it)

I’m excited to see what great ideas people have and hope that the lowered barrier to development will encourage more people to help with development efforts. We expect people to communicate with us as humans but using an LLM to write the code is fine, as long as you can accept that there’s going to be some back and forth before merging anything. Which brings us to the second point of discussion

AI is a really really good software development tool

As with most of the software industry we’ve been adopting LLMs in our workflow. The latest generation is really freaking good. It’s hit a point where getting an AI to generate code doesn’t feel like a compromise anymore. It needs guidance on architecture, and it needs to be told what to do, but it can write code as well as any of us can. And there’s things it does better than us!

Building test infrastructure. We’ve adopted Graham Wheeler’s deluge emulator and are trying to get it as accurate as possible. None of us are experts on QEMU and this has been something we wanted for a long time. Opus has made that possible without needing to find a real expert. Giving it my debug deluge and having it spend nights getting the emulator to match it as closely as possible has been invaluable.
Profiling and performance work. Much of the recent speed-up work would have been extremely tedious. Optimizing code for cache usage is a painful process of trial and error and benchmarking. The LLM can do that for 12 hours straight until it hits something good, I get bored way before that.
Trying different implementations. Getting USB audio to work without a performance penalty was a journey. The LLM was willing to rewrite it a dozen different ways with different tradeoffs until I got something worthwhile. If I was a project manager getting a human engineer to do that I’d have been shot.
Reviewing code.The Deluge is a huge and sprawling system of code, with lots of things that change because of weird edge cases, and AI can help us catch that before we merge. It doesn’t get distracted or make assumptions in the same way we do and that mechanical reading can be very helpful to find errors.
Hairy refactoring. We can have the AI write out a pile of test cases for the current code, then write new code to match those tests millions of times faster than we could do it by hand.

But ultimately AI is not human, and while it can write correct code, someone needs to figure out if it wrote the right code.

AI is not human

A language model has no stake in whether your set goes well. It doesn’t know the consequences of an update changing your sounds right before a gig. It doesn’t know how bad it feels to have a 15 minute set and spend the first 5 troubleshooting.

I gig the deluge at least once a month and go to jams with it almost every week. I am very invested in keeping it rock solid so I’m never worried about it crashing. I’ve been gigging 1.3 for a year and I have never had it crash, but as we all know tons of people do have crashes on our nightly and beta firmware. How is that possible?

I only have my own hardware and my own habits. You have:

Songs that are far bigger and stranger than anything I’d make
SD cards from every manufacturer in every state of health
Controllers, USB devices, and modular rigs beyond my imagination
Workflows I would never think to try (shout out to everyone turning the tempo up to FAST)

Every time someone loads a community build and says “this sounds different” or “this crashed when I did that,” the firmware gets better in ways we could not have achieved alone. Bug reports with steps to reproduce are one of the most valuable things anyone can contribute

How we work together

We need feedback from real users to improve. We want to know how people are using it!

First off test the builds when you can and let us know what you think. Nightly, beta, and release-candidate builds exist so that real use can find the problems before people start gigging them. Something not happening the way you’d expect can be a bug! We want things to be as intuitive as they can be. Even if you can’t say why something feels wrong let us know, “The filter feels different” is a perfectly good bug report. Suggestions and ideas are welcome - the best way to reach us is the dev channels on discord

We need more help than just code! Helping with documentation is wonderful, the web manual is an evolving work and it’d be great to get videos and demos to go along with it.

On being open about AI

We ask you to write the PR descriptions yourself because we want PRs from humans, we don’t want to be spammed by people’s AI agents. It’s our filter to ensure that a real person (ideally a musician) has sat down and thought about whether this change makes the project better. It’s fine to have AI write the code, but we need that human judgement to make sure it’s the right code.

Everything that lands is reviewed by a person who understands it and is accountable for it. If you have a great idea but the code’s not quite there then we can work on it - we’ll give feedback on where we think the problems are and leave it to you to fix them. If you use an AI that’s fine, we just ask that you communicate with us by hand and respect the humans behind the work.

That said everything that gets merged is human reviewed. We make sure changes make sense, follow the UI guidelines, and feel right on the deluge. This is really a “we” - it’s the feedback from the army of beta testers and brave nightly build users that let us get things right.

If you have concerns or opinions about AI in this project please share those too. I miss the pre AI days as much as I’m sure many of you do.

The best firmware is a shared project

The Deluge community has always been the heart of this instrument. It’s the reason it does so much more than it did when the hardware first shipped, and it’s the reason it continues to grow more than 10 years from it’s announcement.

The tools make us faster but the community makes us right.

Mark Adams

Co signed by Sean Ditny and Katherine Whitlock - your deluge community maintainers