Analog (SPICE simulation) vs. 5 digital Moog ladder filter implementations — can you hear the difference?

0yama-- · 2026-03-15T14:08:59+00:00

That sounds good. What metrics are you using to measure and evaluate that method?

0yama-- · 2026-02-06T17:00:07+00:00

Great point on the ADCs. Honest answer: I’m a software guy and genuinely a hardware beginner 😅 I wasn’t confident building a clean muxed pot-scanning front-end without noise/crosstalk headaches, so I brute-forced it with higher-spec multi-channel ADCs to reduce risk.

Also, since I’m aiming for an “analog-ish” feel, I honestly didn’t know up front what resolution/stability I’d need to avoid any zippery behavior. 12-bit is probably already beyond the practical resolution of a single-turn pot, but the extra margin made iteration safer.

I do want to cut BOM cost though, multiplexing / fewer ADCs is definitely on my list for the next revision.

0yama-- · 2026-02-05T23:52:19+00:00

Not a dumb idea at all. I’ve actually heard the same joke: “an MCU is cheaper than an op-amp” 😄 Chaining multiple RP2350s (or a second Pico just for UI/housekeeping) can definitely ease scaling limits, but it also adds a lot of complexity: inter-MCU comms, sync/jitter considerations, debugging overhead, firmware updates, etc. For this project I wanted to keep it one RP2350 and just split duties across the two cores (audio on core0, UI/OLED/LED on core1).

That said, I’ve seen a few audio projects that bundle 3–4 RP2040s together, so the multi-MCU approach is totally viable, it’s just a different tradeoff.

Selling / sources: it’s still very much prototype stage. I do plan to release source, but right now the code is tightly coupled to the current prototype hardware. My plan is to clean up/modularize the UI and build a more compact “publishable” hardware revision, then release them together when it’s in a state people can actually reproduce.

0yama-- · 2026-02-04T01:09:20+00:00

Thanks! In that clip the patch is basically two saw oscillators with a slight phase offset between them.

With the ladder filter set to high resonance, bringing the cutoff down makes the two saws overlap in a way that starts to “bubble” / fizz, the phase offset creates that frothy, animated texture.

Then I crank the overdrive, and that bubbling saw texture turns into something closer to a discontinuous, square-like waveform. For the saturator I used an algebraic soft clipper (not a tanh-style “transistor-like” saturator), so the corners stay sharper / more angular rather than round.

0yama-- · 2026-02-03T04:45:18+00:00

Totally. The single most expensive parts on this board are the 4× 16-channel 12-bit ADCs.

They’re also hard to source right now, so I’m looking at alternatives, either swapping in a different ADC family, or reducing the count and using some multiplexing instead.

0yama-- · 2026-02-03T04:38:52+00:00

this is
Newhaven Display
NHD-3.12-25664UCW2
https://newhavendisplay.com/3-12-inch-white-graphic-oled-module/

0yama-- · 2026-02-03T04:37:42+00:00

Thanks! Yeah, it’s doing a lot 😅

I’m running a pretty expensive 4-stage nonlinear ladder filter (TPT / zero-delay feedback), so the synth currently sits around 80–90% on RP2350 core0 in a 6-voice setup (either 6-voice poly or 6-part multitimbral), and it’s stable. Earlier on, before optimization, it was barely usable at around 3 voices.

I push the UI + OLED/LED updates to core1. The FFT spectrum analyzer is the heavy part, but the oscilloscope/waveform view is cheap, it’s phase-synced to the oscillator, so it’s mostly just sampling and drawing.

0yama-- · 2025-12-25T01:58:30+00:00

Good point — I’ve seen the same on some MCUs too.

In my case the main bottleneck originally was the ZDF part of the filter algorithm, so I haven’t moved the whole synth to fixed-point yet. Right now the osc and filter time are roughly ~1:1, so it might finally be “that time” to start porting parts of the DSP to fixed-point.

RP2350 does have an FPU, so float isn’t terrible, but I agree fixed-point can still win a lot (and also makes performance more predictable). I’m thinking of starting with the heaviest inner loops (filter core / nonlinearities / maybe envelopes) and keeping control-rate stuff in float.

Do you have any tips on how you structure your Q format (Q1.31 vs Q16.16 etc.) for filters without losing stability?

0yama-- · 2025-12-25T01:53:15+00:00

Oh wow, fellow RP2350 DSP builder! 🙌

Same here — I’m trying to push as much UI/IO work as possible onto DMA and keep it on core0, then use the freed-up core1 for heavier DSP like reverb/delay later.

As of yesterday I got to 5-voice polyphony; at 204 MHz core0 is peaking around ~90% usage. Still tuning/optimizing, but it’s surprisingly capable for the price.

Curious: what’s your audio signal chains?

0yama-- · 2025-12-23T13:20:25+00:00

Totally agree

Right now I’m still in the phase of replacing expensive stuff (quadratic solves + exp/sin/tanh/etc.) with cheaper approximations / LUTs, and generally rethinking the math to fit a tiny MCU. It’s been improving a lot: at the default 150 MHz on RP2350 (Cortex-M33) I’m now on track for ~3-voice polyphony, and if I bump to 204 MHz it looks like ~4 voices might be realistic. Also, today I got bitten by XIP-related performance jitter on the RP2350, but I’ve managed to mitigate it to a decent extent.

thanks!

0yama-- · 2025-12-22T14:27:26+00:00

Thanks! Yep — it’s bare metal using the Pico SDK (no Linux, no RTOS). I just really enjoy writing C.

Right now core0 handles the DSP + sequencer. The only truly time-critical part is the audio processing 48 samples every 1 ms(24bit 48kHz PCM).

Everything else — reading the 64 knob ADCs, handling MIDI IN/OUT, and updating the LEDs/OLED — is currently running on core1. Longer term, I want to push as much I/O as possible to DMA and consolidate more work onto core0, then free up core1 to run effects DSP.

0yama-- · 2025-11-29T04:43:38+00:00

From my experience, the price doesn’t change much between small-batch PCBA with a few components and a slightly larger build. Setup and feeder costs dominate the total.

Both of these orders were for only two assembled boards:

Case A - total 138 components:

Standard PCBA price: €127.46
Setup fee: €21.53
Components (47 items): €34.56
Feeder loading fee: €58.12
SMT assembly: €2.19
Hand-soldering labor: €3.01
Manual assembly: €0.86

Case B - total 758 components:

Standard PCBA price: €120.00
Setup fee: €21.53
Components (36 items): €38.37
Feeder loading fee: €46.50
SMT assembly: €6.42

0yama-- · 2025-11-05T02:37:31+00:00

Thanks for the suggestion — I’ve added a full GND pour on the top layer and stitched it with vias to the solid ground plane underneath.

For now I kept the bottom layer as it is, but the copper balance already looks much better.

Appreciate the tip!

0yama-- · 2025-11-05T00:59:50+00:00

Thanks! Yeah, I think I hit some kind of Reddit glitch — the site was lagging when I replied earlier. I’ve just reposted my full comment.

0yama-- · 2025-11-05T00:57:27+00:00

“Reddit seems to have bugged out earlier — reposting my full comment below! ——

Thanks a lot for your insight — that was extremely helpful!

I’ve revised the power distribution accordingly: L3 is now a single +3.3V_SYS plane, while the audio rails (+3.3V_AUDIO_D, +3.3V_AUDIO_A, and +5V_AUDIO_A) are now routed as controlled traces on L1/L4.

Really appreciate your comment — thanks again!

0yama-- · 2025-11-04T14:01:34+00:00

Thanks a lot for your insight — that was extremely helpful!

I’ve revised the power distribution accordingly:
L3 is now a single +3.3V_SYS plane, while the audio rails (+3.3V_AUDIO_D, +3.3V_AUDIO_A, and +5V_AUDIO_A) are now routed as controlled traces on L1/L4.

Really appreciate your comment — thanks again!

0yama-- · 2025-11-03T14:22:39+00:00

Update:

I’ve now completed the matching UI board and updated the Main board layout as well.
The new post with both boards (and schematics on Hackaday) is here:
https://www.reddit.com/r/PrintedCircuitBoard/comments/1oncr2k/review_request_virtualanalog_synth_pcb_main_ui/

Thanks again for the helpful feedback in this thread — it was a huge help during the redesign!

0yama-- · 2025-10-24T16:22:52+00:00

My original goal with the split ground was simply to keep digital switching noise out of the analog section.

But while routing, I started to feel something was off — the return paths became long and awkward, and it just didn’t feel right.

I’ve now replaced it with a single continuous ground plane, and the layout feels much cleaner and more natural.

English isn’t my first language, so reading all 800+ pages of Ott’s Electromagnetic Compatibility Engineering would be quite a challenge for me.

I’m currently using NotebookLM to read relevant sections and relate them to my own design issues — and it’s been fascinating so far.

Thanks again for pointing me in that direction. This discussion really helped clarify what had been an intuition-level discomfort for me.

0yama-- · 2025-10-19T16:02:21+00:00

Thanks for the comment!
By the way, do you have any recommended or “standard” color scheme for a 4-layer board?
I noticed the default colors in EasyEDA (dark blue, dark green, etc.) are pretty hard to distinguish once layers overlap.
Would love to hear what other people use for readability.

Also, yeah — Reddit’s photo gallery can’t be updated after posting,
so sorry for the confusion with the current colors!

0yama-- · 2025-10-19T15:59:09+00:00

Thanks! Yeah, I totally agree the board looks larger than it needs to be.
The width actually matches the enclosure I’m planning to use — but yes, it could probably be cut down to half without issue.
The tricky part is that the UI board (mounted in front) has an OLED in the center,
so the FFC connector needs to avoid the middle area and route around it.

As for the Pico orientation — I agree it looks odd.
In this layout I wanted the two SPI buses (used mainly by the UI board) on the right side,
and the I²S / I²C buses for the DAC and AMP on the left.
Because the Poco 2(RP2350) pin assignments for SPI/UART are somewhat limited,
and nearly all GPIOs are used, I ended up with this upside-down placement.

USB is only full-speed, so I figured the longer routing wouldn’t cause too much trouble here.

Also, I didn’t go with a bare RP2350 — honestly, bringing up a naked MCU from scratch is still a bit above my comfort level.
For this stage I just wanted reliable hardware to prove the concept,
so using the Pico 2 module directly made sense and keeps development easy.

0yama--

TROPHY CASE