alt.hn

6/3/2026 at 7:41:21 PM

Brume is a 24-voice multi-timbral desktop synth for the CM5

https://brume.aftertone.co/

by oceanwaves

6/3/2026 at 7:41:21 PM

I wanted another multi-part hardware synth, so I thought it would be fun to see what I could come up with using the parts I already had, particularly the touchscreen.

Loosely inspired by Norns, Brume is a four-part multi-timbral synthesizer that runs on a Raspberry Pi Compute Module 5. It has four synth engines and six voices per part, a shared filter section feeding an effects chain, a sandboxed Lua scripting layer, and a 10.1-inch touchscreen UI. A single USB cable presents the device to a host computer as a class-compliant audio and MIDI interface ala Elektron Overbridge.

Quick BoM to get started: cm5+carrier, any of the endless 10-inch hdmi touchscreens for RPI, and a midi controller. Novation Launch Control XL 3 and Korg nanoKONTROL2 are supported out-of-the box.

* While you can run this on a Raspberry Pi 5, Pi 5s don't expose USB OTG. The carrier board is what makes the class-compliant Audio+MIDI over USB work.

I hope this can be fun for others!

https://brume.aftertone.co https://github.com/aftertonesignal/brume

by oceanwaves

6/3/2026 at 9:52:52 PM

Neat effort.

You may already know this, but the voice engines implementations have a lot of room for performance improvement, and you could probably squeeze out even more voices, routing patterns, secondary features, etc if you tighten them up.

They're written clearly but kind of like textbook/reference implementations rather than the more aggressively fine-tuned versions you'd see in proprietary commercial synths.

You can probably coach Claude through improving them, but you generally need to do that explicitly.

Lowest hanging fruit for your design would be to have it organize control flow (and apply effective math tricks) to minimize branching and to organize data references with cpu cache more in mind.

On a more ambitious scale, working over blocks instead of samples, and using vector instructions where practical would go a long way. The latency impact of working on small blocks (i.e ~8/16/32 samples) instead of individual samples is irrelevant but the performance opportunities that open up for many algorithms is huge.

by swatcoder

6/3/2026 at 10:03:14 PM

Exactly the kind of feedback I'm looking for, since this is an educational, hobby-class project for myself. I'm just treating the development of it formally as a product to stay disciplined.

Make no mistake, I'm not promoting this thing like a product, though. I'm aware there's a big gulf between this and a commercialized purpose-built product.

That said, there is a ton of headroom right now on the 8GB CM5 reference platform and I felt some of these optimizations were overkill in this pre-1.0 phase. The FX bus is already block-based, but the voice synthesis path remains pretty simple. Some of the block scaffolding for the better approach exists and I'll plan to evolve in that direction.

Thank you.

by oceanwaves

6/4/2026 at 12:43:23 AM

I don't know how intentional this was, but it Just Works on macOS. It builds and runs, with UI. I have an OP-1 field attached and it takes the MIDI notes and synthesizes sound. I can't imagine why it wouldn't Just Work with a DAW sending MIDI as well - no need for external hardware, at least on Mac!

by jagged-chisel

6/4/2026 at 12:48:32 AM

Yeah that's by design, and kind of a nifty byproduct. The demo tune on the landing page was actually generated by the DSP engine running on macOS. For me, it's mostly a development aid but you can use it that way if you wanted.

Just wasn't part of the motivation. I wasn't looking for another standalone macOS app or VST. Wanted something tactile (controller I already have muscle memory with) and a touchscreen UI.

by oceanwaves

6/4/2026 at 1:00:26 AM

I certainly don't mean to minimize the work - you've done a fabulous job! I went off to find the hardware to assemble and the prices are kinda nuts... It's awesome having the option to run it on something I already have.

by jagged-chisel

6/4/2026 at 1:06:17 AM

Oh man, the prices of these components have skyrocketed since I began this project. It has been depressing to watch.

by oceanwaves

6/3/2026 at 11:04:20 PM

Very well done! I'm very inspired by the Lua scripting layer, this seems to be just a great solution.

by rigonkulous

6/3/2026 at 9:53:51 PM

Just out of curiosity, and without judgement, how much ai was involved in building this (ie was it vibed)? I'm trying to get a better idea of the kind of stuff people are making.

by Fraterkes

6/3/2026 at 10:11:28 PM

A -ton-

No hesitation to enthusiastically share that it was actually a parallel goal to see just how deeply I could go while keeping it stable, performant, and extensible for the long term.

I ended up building a lot of ancillary agent infrastructure to push the determinism in all the fanned out work slices, too.

https://thinkwright.github.io/threadmark/

Also: https://brume.aftertone.co/develop.html#agents

by oceanwaves

6/3/2026 at 11:05:27 PM

Did you give any thought to using JUCE as a general framework? This way you could add more synths very easily ..

(Apologies if you already do, haven't looked for sources yet..)

by rigonkulous

6/3/2026 at 11:12:03 PM

I do distribute VST/AU plugins that are built with JUCE, but this is an application that runs on the Raspberry Pi platform.

by oceanwaves

6/4/2026 at 12:05:46 PM

JUCE runs great on Raspberry Pi.

by rigonkulous

6/4/2026 at 5:27:14 PM

Even in my plugins, I don't actually use JUCE DSP primitives. It's mostly a product shell and distribution framework, two things I have no need for in this codebase.

by oceanwaves

6/5/2026 at 9:40:40 AM

I understand .. but its not 'mostly a product shell' and distribution framework, there are a lot of things JUCE brings to the table that might've been useful in this context, such as being able to host plugins and adjudicate resources (shared memory primitives, extremely easy parameter setup and management across DSP and MIDI frames, easy integration of common codebases into both DAW and standalone versions, etc.) that are generally good for DSP .. you're not obliged to use JUCE's DSP incidentally, I have my own synth project based on JUCE with both ARM and x86 SIMD implemented side-by-side .. JUCE' primary value is as a runtime environment, which I guess you are more interested in setting up, yourself, and I get that, so yeah ..

by rigonkulous

6/3/2026 at 8:23:53 PM

The demo song sounds fantastic. I'm never going to have a time to build this, any chance it can be turned into a plugin?

by oidar

6/3/2026 at 9:50:06 PM

Hey, thanks. Kind of obsessed over that demo for too long.

The Rust engine underneath isn't even Pi-locked. It'll run on macOS/Linux, but the touch UI and USB-audio bridge is device specific so it would be fairly useless.

You might be over-indexing on "build this". It's actually just slapping a few 1-click shopping parts together and running two commands in your shell to have a playable instrument.

I've got a vague idea to maybe pull the FM engine out some day since I love having a DX-style synth that actually has a filter, but my plugin work is generally focused on effects processing and not voicing, so I dunno...

by oceanwaves

6/4/2026 at 12:14:03 AM

What are the chances this would run on CM4 instead?

by jagged-chisel

6/4/2026 at 12:36:10 AM

It should run ok on a CM4, but with some limitations.

Less DSP headroom; swatcoder's optimization suggestions in this thread become more important. Simultaneous 4-part polyphony might push things. You'd probably want at least a 4GB board.

Also, the brumectl installer will not attempt to set up the USB audio/MIDI bridge (Meridian) on a CM4. That auto-configures only on a CM5 for now.

Would be a pretty light lift to get that working if you are interested.

by oceanwaves

6/3/2026 at 10:10:02 PM

There isn't a single image of the device on mobile, I was confused because I thought this was a VST

by Zetaphor

6/3/2026 at 10:14:33 PM

The copy makes it pretty clear this is firmware for a CM5.

Rest assured, if you click the "READ THE MANUAL" button on the landing page you will see screenshots of all synth engines and configuration screens.

The repo's README also starts with a screenshot.

Thanks.

by oceanwaves

6/3/2026 at 10:29:37 PM

To be fair, it doesn't seem to be mentioning this until the "Purpose-built on Compute Module 5" section which is more than halfway through the entire landing page, I was similarly lost until I got to that section and actually understood what I was looking at :)

Looks really fleshed out and fun though, now I just need to get my hands on a proper carrier board it seems, as the audio out of the box for standard CM5 development I/O board is kind of horrible.

by embedding-shape

6/3/2026 at 10:34:58 PM

Thanks, I'll try to improve the reader experience.

by oceanwaves

6/4/2026 at 1:32:53 AM

They clearly missed that part where I said I'm on mobile. That half a page is a lot longer on a smaller screen. Also I still want to see a picture or video of this running on actual hardware!

by Zetaphor

6/4/2026 at 1:44:15 AM

I've actually fixed the page based on your feedback. Not sure why you continue to be bothered by my open source hobby's landing page.

https://brume.aftertone.co/lcxl3.png

Cheers.

by oceanwaves

6/3/2026 at 10:37:37 PM

And yeah, line-out audio on a Pi is a non-starter.

This was really designed to be surfaced in a DAW via USB.

by oceanwaves

6/3/2026 at 10:41:17 PM

Oh, yeah I actually missed that fully, that it expects a USB-connection. Would be a lot of fun and I could find a lot of uses for something like this in my DAWless setup, but with audio-over-USB there isn't much I could do at the moment, but since it's Linux, just changing the output (once I have a new carrier board...) shouldn't be so hard. Thanks for sharing it :)

by embedding-shape

6/4/2026 at 12:43:32 AM

For the DAW-less use case, I actually prototyped this with a DAC hat before deciding to go the Overbridge route. I might resurrect that support some day...

by oceanwaves

6/4/2026 at 1:30:18 AM

I don't understand why, if you want to use this, would you run it on RPi instead of just on your computer? Is it for realtime guarantees (ie. no OS updating in the background)?

by Quiark

6/4/2026 at 1:42:43 AM

Yeah, I understand the lens through which you're probably evaluating this. Wouldn't be for you.

I wanted to design, learn, build, and have fun with something physical on my desk that I could swipe, turn, twist, and make sounds with.

https://brume.aftertone.co/lcxl3.png

Just a hobby project I'm sharing.

by oceanwaves

6/4/2026 at 4:16:17 PM

Actually as a proud new owner of SuperCollider and a breadboard (and Taobao account) I'm not very far from getting a few rotary encoders myself ...

by Quiark

6/4/2026 at 5:47:37 AM

I've been looking for an excuse to get a RasPi for a long time ... this could be it!

by 8bitsrule

6/3/2026 at 9:01:56 PM

dig the idea.

by reality_inspctr

6/3/2026 at 10:23:53 PM

[dead]

by ConanRus