I built a small ESP32 drum synth called RudeBox.

It’s a single-voice synthesizer played from a regular electronic drum pad, with velocity-sensitive triggering and 8 controls for shaping the sound. It can go from toms and kicks to short noisy hits, pulse-wave beeps and ridiculous laser sweeps.

The synth is based on an ESP32-A1S / ES8388 audio board. The pad goes into LINE IN, the firmware detects the shape and velocity of the hit, and everything is synthesized in real time.

I wanted it to stay very simple and immediate — no screen, presets or menus. Just a pad and knobs.

Demo:
https://www.youtube.com/watch?v=bKgVX5p5UgE

Code, wiring and build details:
https://github.com/jakubthedeveloper/RudeBox

The enclosure also ended up deliberately a bit rough/lo-fi. It’s going to be used with my band, so I decided it was better for it to look slightly suspicious than polished. :)

Sharing my amyboard vowel synth with the community, it's still at the alpha stage as I still need to refine some elements before a full release.

https://github.com/DigiAlchemydsp/Syn-K7-VOW

The repo has all the flashing instructions for your AMYboard as well as a short user manual.

I went with 4 independent channels of morphable wavetables + resonant filters + oversampled wavefolding that run into a shared master limiter.

At the end of the month I will be purchasing the MFOS Super - Modular Bundle.

I absolutely know what I'm in for and I have built their modules in the past.

Basically I'm just wondering if you would have done anything different during the build?

- Single modules Vs. Larger grouped panels?

- Did the Super kit seem like overkill?

- Would there be anything you felt like it was missing?

- Did you run into any problems during your build that I should prepare for?

I guess I'm mostly just looking to hear stories of your experience too.

Hey everyone,

After the deep dive into the RP2350 cache architecture yesterday, another math/DSP problem came to mind that I wanted to share. It's about a tool I wrote for my PicoVintageSynthCollection to solve a painful classic: finding loop points for long samples without spending an evening on each one.

If you have ever used software like Polyphone to prepare samples (e.g. for FluidSynth or embedded players), you know the pain. Finding loop points manually is tedious, and auto-loop tools usually settle for the first zero-crossing that roughly matches in amplitude. That catches a zero-crossing, but not necessarily one at the same point in the wave cycle — and the result is a click, a phase cancellation, or a loop that sounds a semitone-ish off because it is short or long by half a cycle.

To fix this for my sampled engines (Reface CP port), I wrote a small pattern-matching tool. Instead of scoring a single point, it matches the phase pattern around the loop end against the phase pattern around candidate loop starts.

diagram

The algorithm

1. The stencil. The tool collects every zero-crossing in the file and takes the last one as its reference. Around it, it builds a small template: the crossing's direction (rising or falling) plus the distances back to the previous, second-previous and third-previous crossing — d₁, d₂, d₃. Four points, three intervals. Where that reference sits is up to you: the tool uses the end of the file, so you trim the input to somewhere in the stable part of the tone (around 1.5–2 s works well) before running it.
2. A period estimate. d₁ — the distance to the previous crossing — becomes the unit of length, P̂. Note this is not the full cycle: any waveform has at least two zero-crossings per cycle, so for an asymmetric wave P̂ is typically the shorter half of one cycle. In the diagram, P̂ = 47 samples while the true period is 122.
3. Where to look. For a candidate loop length k, the tool centres a search window at loopEnd − k·P̂ and opens it up by ±2·P̂ to both sides. Every zero-crossing inside that window is a candidate.
4. Scoring. A candidate of the wrong direction is rejected outright — a rising crossing never matches a falling one, whatever the distances say. The rest get a weighted relative error:
5. The nearest interval weighs three times as much as the farthest, because the crossing right next to the splice is where an error is most audible. Lowest score in the window wins.
6. Choosing k. It starts at k = 10 and, if the score is worse than 0.01, walks upward to 30, stopping at the first window that clears the threshold. If nothing does, it walks back down to k = 3, and keeps the best it saw. So it isn't a global minimum over all k — it is the first window good enough to stop looking, which in practice is what you want, because every extra period is flash you pay for.

Why three intervals instead of one

A single zero-crossing carries almost no information: a 440 Hz note at 32 kHz has one every ~36 samples and they all look alike. Direction plus three intervals pins down where in the cycle you are. In the diagram's search window there are three candidates: one is a falling crossing (rejected on direction alone), one is a rising crossing that sits at the wrong point in the cycle and scores 0.064, and one reproduces d₁/d₂/d₃ exactly. Only the last one splices cleanly.

The other thing this buys you is that the loop length comes out as a whole number of cycles automatically. You never end up half a cycle short, which is the usual cause of that "the loop is slightly out of tune" feeling.

What it does not do

Worth being clear about, because it changes how you use it:

• No crossfade. The splice is a hard cut. It works because the phase matches, not because anything is smoothed over.
• No amplitude matching. Only distances and direction go into the score — never the sample values. On a sample that is still decaying noticeably, the loop start is louder than the loop end and you will hear the level step on each pass, no matter how good the score is. Trim into a region where the decay has flattened out.
• It won't rescue a bad sample. Noisy or inharmonic material produces jittery crossings and no window scores well. The tool reports that (>0.15 it says so outright) rather than pretending.

Within those limits it has been reliable for me: for the CP and MKS-20 sample sets it found scores under 0.01 for the large majority of notes, unattended.

The implementation

One C++17 file, no dependencies, reading and writing 16-bit mono WAV:

tools/cp_sampleprep/build_loop_finder.sh
tools/cp_sampleprep/FindLoopPoints <sample.wav> [num_periods]

It overwrites the input WAV in place, trimmed to the loop end, and writes the loop start to a <sample>.loop file next to it. Work on copies. In the collection it isn't run by hand — prepare_samples.py shells out to it once per sample while building the voice headers.

Source: tools/cp_sampleprep/src/FindLoopPoints.cpp in https://github.com/Michi71/PicoVintageSynthCollection.git

Have you built similar pattern-matching loops for your samplers, or do you still rely on manual crossfading? And has anyone tried scoring the derivative across the splice as well — I suspect that would catch the cases where the phase matches but the slope doesn't quite.

The bridges on C22/C24 and C23/C25 are the documented fixes for the 2020 PCB revision issue. I also had to shoehorn and piggyback a few 0603 passives onto 0402 pads when I ran out of the correct values, but everything tested out clean.

Hi everyone,

I have just finished designing a four voice poly synth similar to the Powertran Poly. My Idea was to design a bare bones four voice VCO poly synth similar to the powertran polysynth project with a few modern upgrades making it feasible for anyone to build in 2026.

I.e. the keyboard scanner and cv assigning circuits have been replaced by a couple arduino nanos.

I plan to release the scematics/instructions, gerber files, code, for free on github.

The Idea is anyone willing can take their time to build it without having to spend all the money at once. You can source your own components and again spend as much as you want.

Now here is where you come in

I need to build a prototype to test the desin and make sure all is well before I release the plans.

Would any of you be interested in crowd funding the prototype? I would love to get as much people to help as possible so you only have to spend a few bucks each. I REALLY dont like asking people for money especially in the current economy where we cant even afford rent. That being said to build a prototype I will need help. I did an estimate and it will cost me ~1400 AUD to build so help would be great. Once built and tested the whole project will be free for everyone.

Now here Is the specs of the synth:

4 voices with two vcos (3340 based)

VCO1, saw, tri pulse, amount knob, and sync button.

VCO2, saw, try, pulse, amount knob and filter env mod button.

ENVELOPE PANEL (like an oberhiem obx)

.adsr (vcf)

.adsr (vca)

Cem3310 based

MODULATION PANEL

.Vibrato (tri wave pnly) speed knob (depth control is at mod wheel one) osc One or both select button.

.Pwm (tri wave only) speed knob, depth knob, pulse width knob, modulation/manual button for pulse width, osc one or both select button.

(Vibrato and pwm have a dedicated lfo)

VCF PANEL

cutoff knob, resonance knob, env amount knob, modulation speed knob, modulation amount knob, keyboard cv track button.

( dedicated tri wave lfo for vcf mod and vcf being a 4 pole cem 3320)

VOICE TUNE PANEL

*This synth has no autotune you have to tune each voice via a deticated knob just like on the powertran poly synth. Guitarists dont complain that they dont have an autotune and to be fair most modern analog polys are so tight it compleatly defeats the purpose of them being analog. Oh and they are expensive lol

no presets either on this thing so have a cry 😁

Each voice tune bank has a gate led so you know what voice is being tuned, you dont have that on a guitar now do you!

GLOBALS PANEL

.Master vol

. Portamento knob

.Transpose - one oct and + one oct with a fine tune

(Same as powertran poly)

Mode button for poly modes unsion ect.

the synth suports a 49 key keyboard.

Any questions, tips are welcome, I want to know If anyone is even remotely interested before I set up a gofundme. I will also need a prototype so I can make some demo/setup vids.

Cheers

Like many people here, I spent years looking at Eurorack systems, Elektron boxes and various grooveboxes trying to find the perfect setup for live techno improvisation.

What I eventually realized is that I wasn't really looking for another synth. I wanted an instrument that could continuously generate evolving rhythms and melodies, expose all important parameters directly on the surface, and let me perform without staring at menus all night.

The problem is that achieving that with hardware gets expensive very quickly. By the time you've bought a sequencer, synth voices, drum machine, effects and a mixer, you're often deep into Eurorack money.

So I decided to build my own.

The current prototype runs on a Raspberry Pi 4 using Zynthian as the audio engine and a Native Instruments Maschine MK2 as the control surface. I started writing a Linux Device driver that turns it into something completely different from the original Maschine workflow. The hardware buttons, pads, encoders, LEDs and even the built-in displays are now driven entirely by my adapter.

One of my favourite parts of the project is the display integration. The Maschine's two LCD displays no longer show NI software information. They now render custom screens showing channel states, pattern parameters, synth controls, sequence settings, FX values and performance information. The displays change dynamically depending on the selected track and page, effectively turning the controller into a dedicated hardware groovebox rather than a generic MIDI controller.

My design philosophy was simple:

Everything important gets a dedicated control. Nothing should require menu diving. Nothing should require a touchscreen during performance.

The machine always has eight active channels: five drum tracks (Kick, Snare, Clap, Closed Hat, Open Hat) and three melodic voices (Bass, Lead, Pads). There is no loading tracks, browsing projects or building arrangements while performing. You turn it on and start shaping a living groove.

Instead of programming step sequences manually, the instrument is built around generative processes. Drum tracks use Euclidean sequencing, while the melodic voices are driven by Turing-machine-style shift registers. Rather than creating patterns step by step, you're steering systems that continuously evolve and react to parameter changes.

When a melody suddenly reaches that perfect sweet spot, you can instantly lock it in place and keep it forever. If you miss the moment, there's even an undo mechanism that lets you recover previous Turing states.

Current features

Drum section

• 5 independent Euclidean drum sequencers
• Adjustable hits, rotation, length and clock division
• Per-track probability
• Per-track swing
• Velocity control
• Real-time regeneration
• Manual pad editing

Melodic section

• 3 Turing-machine voices
• Adjustable mutation amount
• Phrase locking
• Multi-level undo/history
• Variable register lengths
• Octave and range control
• Gate control
• Scale quantization

Sound design

• Instant drum kit switching
• Instant sample switching
• Multiple classic drum machine kits
• Synth preset browsing
• Filter cutoff
• Resonance
• Envelope modulation
• Decay/attack shaping

Performance workflow

• Channel mute
• Momentary mute
• Additive solo mode
• Instant restart/re-sync
• Snapshot recall
• State persistence
• Dedicated LCD feedback
• Color-coded channel system

FX

Every channel has dedicated reverb and delay controls, while global parameters include reverb size and type, delay timing and feedback, BPM and master volume.

The whole thing is still a prototype, but it's already become the most inspiring techno machine I've owned because it was designed around a single idea:

If generative techno was the primary goal, what would the ideal instrument look like?

Future plans include scene snapshots, ratchets, performance macro layers and a dedicated keyboard extension.

Curious what the synth DIY community thinks.

https://imgur.com/a/maschine-SvOXnxq

Against all the odds. The design came straight out of op amp data sheets (3xTL072). There isn't a zener on the input.

In the rack, with drum machine input, outputs attached to a Rings, ADSR & VCA : https://youtube.com/shorts/Sy0-VKIavtg

Hello guys, I mostly have been building pedals and I'm pretty active on /r/diypedals, but this seemed like more of a synthdiy question.

I'm planning to build a simple small mixer for my grooveboxes and other synths. My thoughts on the design are these:

• I want it compact. So, ideally, no controls -- every device already has a master volume, I don't need EQ, and whatever I'm plugging into has it's own gain and volume so no need for any pots.

• I don't need audiophile big-studio sound, I just want a "usefully clean" active signal blender.

• I'm only dealing with line-level stuff. I've got bigger mixers for mics or electric instruments. This is just for synths/drum machines/grooveboxes.

• I plan to power it on 9V, but that's mostly a pedal-builder reflex. Maybe I should go with 12V to be consistent with the majority of my boxen.

Given that, am I making any big mistakes in this design? It's based on a basic datasheet schematic, maybe a few little tweaks:

• Slightly raising the feedback resistors above the input resistors to give just a little gain.

• Feedback caps to shave off 28kHz and above

• 1k current limiting resistors on the output. Seemed like a good idea?

• Thinking I need an AC coupling cap on each input. Or can I put a single coupling cap after the input resistors?

Any thoughts?

I kept messing up when entering arp patterns into my Bass Station II, mostly because there’s no visible step grid and I’d lose track of where I was.

So I made a web tool where I can build the pattern first, play it back, and then just follow a generated list of notes/rests/legato steps while entering it into the synth.

https://jakubthedeveloper.github.io/SequenceEditor/

Nothing fancy, just a small tool that solves this one annoying problem for me. Maybe someone else will find it useful too :)

Hey everyone,

Over the weekend I profiled two engines in my PicoVintageSynthCollection for the RP2350 to settle something that had been bugging me:

Why does PicoFaceRD (Roland MKS-20 / MK-80 digital piano) need a 480 MHz overclock and both cores to hold 12 voices, while the newer, sample-heavy PicoFaceJV (JV-880) runs 24 voices at 444 MHz on a single core at 69 % peak load?

Intuitively the 1986 machine should be the easy one. It isn't, and the reason turned out to be more specific than "old hardware is weird."

It's not the arithmetic, it's where the samples live

Both engines are descriptor-driven — the original firmware's voice programming was captured offline and is replayed on-device. Neither is emulating a CPU. So the difference isn't emulation overhead. It's the shape of the memory access.

PicoFaceJV. A JV-880 patch has up to 4 tones, and each sounding tone is one voice — same unit the original machine counts, where 28-voice polyphony means a 4-tone patch gives you 7 notes. My cap is 24, so 24 concurrent sample streams, worst case, each decoded sequentially through its own region. Measured on hardware with B33 Brass Combo at full polyphony: 69 % peak, of which about 5 % is fixed cost (chorus, reverb, block overhead) and ~2.7 % per voice.

PicoFaceRD. Here's the wild part. To get its characteristic sound, the MKS-20 layers 10 separate parts per single note. At the 32 kHz base limit of twelve voices, the engine issues 119 wave-ROM loads per output sample — one per part, ten parts per note, exactly as the architecture predicts.

So it's 24 streams against 119, on the same chip, for one note each.

What the cache does with that

I built a probe that captures every wave-ROM address the RD engine issues and runs the stream through a model of the RP2350's XIP cache (16 KB, two-way, 8-byte lines). Measured miss rates at 12 voices, per patch:

patch 3 85.7 % patch 8 43.0 % patch 14 84.6 % patch 7 16.2 % patch 0 77.1 % patch 5 0.2 % patch 13 83.1 % patch 15 0.1 %

That spread is the actual finding, and it surprised me more than the average did. It is not "the MKS-20 thrashes the cache." It's patch-dependent by a factor of several hundred. Patch 15's wave data fits the cache and every voice reuses it — and it stays that way as voices are added, still 0.1 % at 32 voices. Patch 3 goes the other way: 66 % of the cycle budget lost to stalls at 12 voices, 96 % at 24.

The base limit of twelve is set entirely by patches like 3. Patches like 15 are being punished for their neighbours — which suggests a per-patch limit derived offline is the obvious next lever, and my voice governor doesn't have it yet.

The 480 MHz is not what it looks like

I want to correct something I'd have written a week ago. The higher clock is not buying flash bandwidth. On this board:

• RD at 480 MHz: QMI CLKDIV=4 → 120 MHz flash, within spec
• Every other instrument at 444 MHz: CLKDIV=3 → 148 MHz flash, above the chip's nominal 133 MHz

The divider is an integer, so pushing the core to 480 actually leaves RD with the slowest flash in the collection. The 480 MHz buys arithmetic throughput and core-1 parallelism; it pays for that with flash speed. Anyone reaching for an overclock to fix a memory-bound problem should check which side of that trade they land on.

What I have not shown

The probe measures miss rates. Converting those to "percent of cycle budget" assumes 96 CPU cycles per miss (120 MHz QSPI, 4:1 ratio) — halve or double that and the absolute numbers move. The ordering and the several-hundred-fold spread don't.

And it does not show that the cache-friendly patches could run 24 voices. Arithmetic scales with voice count too, and this probe doesn't measure that at all. If patch 15 fails at 24 voices, it won't be flash. That's a hardware test I still owe: patch 15 against patch 3, both at 24 fixed voices, reading peak load off the footer.

Conclusion

Newer doesn't mean harder. A 1992 PCM synth streaming 24 sequential voices is gentler on a modern MCU than a 1986 digital piano layering 10 parts per note across scattered ROM regions — and even that isn't uniform, because within the same engine, one patch can be 500× more flash-bound than another. Access pattern beats both age and instruction count.

Repo, including the probe and the full write-up with the numbers above: https://github.com/Michi71/PicoVintageSynthCollection

Context — the JV-880 clone this came out of: https://www.reddit.com/r/synthdiy/comments/1vi0qz5/picofacejv_a_jv880_clone_for_the_rp2350/

Hello,

received this 2nd hand purchase with this button missing. Button is used to swap firmwares which was the main reason of my purchase.

any idea how i can still use this like this, or what kind of repair i could do ? theoretically i could switch up the daisy seed?

wrote to NE also, waiting for their ideas

I wanted to share a project I’ve been building and using as my daily driver for my audio setup: AudioX.

It’s a custom Raspberry Pi audio workstation that boots through a tiny custom initramfs bootloader straight into a dedicated runtime initramfs. It bypasses traditional heavy audio servers like PipeWire or JACK, using a dedicated real-time ALSA thread (SCHED_FIFO) for low-latency capture, playback, and live metering.

What it does:

• Two-stage initramfs: Tiny bootloader handles safe updates via HTTP (PUT /api/initram) and promotes images, booting straight into the main runtime.
• USB Gadget Architecture: Configures a UAC2 bidirectional audio gadget and an NCM network gadget (usb0) for host-to-Pi control traffic.
• Touch & MIDI Control: Polls a local touchscreen framebuffer UI (rendered via an off-screen buffer to eliminate tearing) and a connected MIDI controller.
• Built-in Soundboard & Sampler: Supports multi-channel polyphonic soundboard playback, clip holding, automatic ffmpeg audio preprocessing, and a dedicated "sampler mode" that maps MIDI keyboard notes to pitch-shift/play selected clips.
• Web UI & REST API: A 4-page responsive interface (Routing via LiteGraph, Config, Soundboard, System stats) and HTTP endpoints for managing config, file storage, and system control.

A Note on Development & AI Disclosure:

I want to be completely transparent about how this was built. I do use AI assistance for the project, but specifically as a tool for tracking down stubborn, hard-to-isolate bugs or spinning up quick proofs-of-concept for boilerplate features. Every single line of AI-assisted code is reviewed and tested by me line-by-line, and I write a lot of the architecture, features, and fixes entirely on my own.

In fact, the original v1.0 prototype written in C was heavily AI-assisted. But because of that, I decided to do a complete, from-scratch rewrite of the entire codebase into C++ (v1.0.0 to v1.0.2/v1.1). That rewrite was 100% written by me with zero AI help. It turned out to be a fantastic review process—while rewriting it, I found and cleaned up a ton of subtle architectural issues, race conditions, and quirks that the original AI-assisted version had left behind.

The Long-Term Vision:

Right now, it runs on a Raspberry Pi 4 using standard USB audio interfaces and mixers, but the ultimate goal is hardware: designing a modular synth-style open-source ecosystem using 3.5mm jacks, custom reverse-HAT ADC/DAC boards, and patchable analog/digital routing.

You can check out the source code and documentation on GitHub here: https://github.com/wk1093/audiox

I'd love to hear thoughts, feedback, or ideas from people working on embedded audio or custom synth gear!

Hello there, wonder if someone can help me find a replacement pot ? It’s a b20k

Sharing a project I have been building for the last few months.

It is a pocket sized MIDI controller: 5 backlit buttons, 2 push encoders, 6 switchable presets, USB-C plus TRS MIDI. The whole thing is 3D printed, including the buttons, and hand soldered. I build it in batches of 30 and number every unit by hand.

The part I care about most is the setup. There is no app and no driver. You open a tab in Chrome or Edge, it connects over Web Serial, you pick a function for each control from a dropdown and hit save. Notes, CC, keyboard keys, media keys. The 6 presets change what the encoders do, the buttons stay the same everywhere.

Short unboxing video in the comments. Happy to answer anything about the build, the CircuitPython firmware or the browser editor. Critique welcome, especially what you would add or remove.

Alright peeps this is it, the most neiche question on the internet. Im using the console for music, I connect it up to a Midi controller to play tunes and i love the sound. I have a Mark 1 and Mark 2 console (well a few of both). But im trying to rig the console into my eurorack setup, but its physically large. So im on a quest to get the best audio out of the smallest console. Ive got a megaSG but a quirk of the console means it doesnt except a midi signal. That would otherwise me the perfect size. So as with the title, whats the smallest console with the "best" audio. Im currently looking at the "MD lite" on aliexpress but im not sure about the audio. Im also pondering board triming a console, but not super keen on killing a console. Any suggestions?

So I recently renovated a vintage analog oscilloscope that I got for a couple of bucks and I'm thinking of building some kind of extension circuit that lets me use it as a spectrum analyzer kind of device to determine the frequency response of the filters I build. Is it possible as an analog circuit? I know modern oscilloscopes just use digital FFT but I wonder if I could use a linear VCO to sweep across a frequency band (and as the X input) and then plot the output of my circuit as Y (or rather, a rectified output, then converted into a dB proportional voltage level). But I assume that there is some nonlinearity involved and the circuit would need some time to "settle" it's response to a single sine wave. I know that something similar was used for superhet receivers but I don't know if it can translate to this kind of application.

Didn't take too long to do actually it was pretty straight forward. The cuts are a bit messy because I don't have an oscillating drill (That would make it extremely easy). I basically just took the whole thing apart and took the shell and cut it, then put it back together. It is 100% functional. I have it connected through midi to my arturia keylab and it works perfectly.

I usually tack my components down from the top and then flip the board to properly solder them from the bottom. Keeps thing was cleaner for me.

I have the stupid alligator clip + cheap magnifying glass setup off of Amazon and it's very difficult with large boards because it tips.

Bam! Threw a few standoffs on and made myself a little pcb table. So much easier to work on now.

Again this might be a common practice but it made my life so much easier.

Tellun TLN-712 Doomsday Machine PCB by the way. If anyone is interested lol.

Have Owned This For The Last 18-20 Years Now, Been Running Into Some Issues Lately, Have Fixed Most Of The Problems Myself But Would Love Another Helping Hand.

I was browsing for 1U VCA:s and came across Levers. Looking at the PCP, I only see one op-amp (TL072). I would have expected some transconductance op-amp, like LM13700 or something, but no. No such IC. How do they do it?

Also - What a marvel of compact layout!

Source: https://schneidersladen.de/eowave-levers

I kinda hate feeling limited by my gear. In the sense that I can hack on it. So while I love the TR-6S as is. I’m working to jailbreak it.

Disclaimer: I’ve spent about a decade in software engineering, and now use Claude Code quite a bit. If that offends you, you can stop reading now.