logoalt Hacker News

oceanwavesyesterday at 7:41 PM7 repliesview on HN

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


Replies

jagged-chiseltoday at 12:43 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!

show 1 reply
swatcoderyesterday at 9: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.

show 1 reply
Fraterkesyesterday at 9:53 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.

show 1 reply
rigonkulousyesterday at 11:04 PM

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

jagged-chiseltoday at 12:14 AM

What are the chances this would run on CM4 instead?

show 1 reply
oidaryesterday at 8:23 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?

show 1 reply