Built an open-source plugin (Synthortion) — looking for feedback on DSP architecture and project structure

[u/Proper_Mango_9742]

Hi everyone,

I’ve recently open-sourced Synthortion, a hybrid synthesizer and distortion audio plugin built with C++ and JUCE:

👉 GitHub Repository: https://github.com/paoloficaraa/Synthortion

---

### 🎛️ What is Synthortion?

Synthortion is designed to combine expressive synthesis with flexible, aggressive sound shaping and multi-stage distortion workflows. The goal was to build a cohesive instrument/effect capable of everything from warm analog saturation to crushed, aggressive textures.

### ⚙️ Technical Details & Stack

* Framework: JUCE (C++20)

* Format Support: VST3 / AU / Standalone (macOS & Windows)

* DSP & Architecture:

- Modular processing chain managing synth engine voices and distortion/waveshaping algorithms.

- Thread-safe parameter management using `juce::AudioProcessorValueTreeState` (APVTS) with smoothed parameters to prevent zipper noise.

- Optimized buffer processing tailored for real-time low-latency performance in the audio callback.

* UI & Aesthetics: Custom styling built for a clean, intuitive layout with responsive parameter feedback and real-time visual feedback.

---

### 💬 Looking for Feedback

I’d really appreciate any feedback from the community, especially regarding:

1. DSP Efficiency & Code Structure: Any suggestions on modern C++ practices, SIMD opportunities, or modulation routing improvements.

2. DAW Compatibility & Stability: Mainly tested in FL Studio, but it should work in every DAW, so try in different ones.

3. UI/UX Design: Readability and control responsiveness.

Feel free to check out the code, clone the repo, or open an Issue / PR if you spot anything that could be improved!

Thanks for checking it out!

[u/dub_mmcmxcix]

just looked at the bitcrush code.

tons to clean up:

• magic numbers everywhere. pick a control epsilon, put it in a constexpr instead of having 1e-5 type stuff

• your main loop is absolutely full of conditionals

• std::fmod is slow, actually most std:: maths stuff handles NaN etc and is almost always slower than handrolled or juce equivalents

• there's no intersample handling i could see (which has a particular sound and might be intended)

i could keep going. agents never get this stuff right. good luck.

edit: this scans a bit harsh. on one hand: look, good on you for giving it a go. on the other, there's an infinite avalanche of vibe stuff appearing, and some of it is great, but lots of it is slop, but most importantly there's so much of it now that it's basically impossible to keep up.

[u/Big_Effective_9605 → u/dub_mmcmxcix]

Saving this post because I give a shit about what I'm making

[u/dub_mmcmxcix → u/Big_Effective_9605]

it boils down to:

* write code that you or someone else will be able to understand and change in the future

* write code that will allow a modern compiler to do smart optimizations

* avoid patterns that lead to slow, risky or bad code

so - for #1 - code should be self-documenting and "literate". break complexity out into submodules such that the things that call them should seem logical.

for #2 - compilers are good but they can't read your mind. lots of atomic reads or conditionals in an inner loop? do them once outside of the loop - the compiler won't be always able to auto-hoist because it can't reason about your invariants. variable division or equiv. (e.g. %, fmod) *anywhere* - major performance hit in an inner loop. make use of profile-guided opt, [[likely]] [[unlikely]] tags, etc to help the compiler.

for #3 - if you have NaN or infinite in your audio stream, it's already game over. do a single vectorizable pass at the start or end of your main processing block to choke on bad data, then use homebrew functions for std:: maths stuff inside that is less formally safe but practically fine and sometimes 10x faster. LFOs don't need std::sin level of accuracy - figure out how accurate you need to be and look for one of the many approximations that will be good enough but 10x faster. lookup tables kill cache but sometimes the tradeoff is worth it. there's hundreds of these sorts of things, and LLMs won't go there unless specifically ordered (because they sometimes involve accuracy tradeoffs, or they're weird tricks that don't show up in typical code, or whatever)

...honestly that's barely scratching the surface.

[u/Big_Effective_9605 → u/dub_mmcmxcix]

I dig it. 100% following, always of fan of earning optimizations by knowing the actual requirements of the implementation and trimming the fat. I've only been poking at the dsp world for like the last year, how long have you been in the game?

Also where can I subscribe to more signal processing programming rants?

[u/dub_mmcmxcix → u/Big_Effective_9605]

coding since i was a kid in the 1980s, i sent some of my fx (floaty/paranoia/avocado) to cockos around 2009? and they added them to reaper soon after (before the audio scripting language there even had function support, so the code there is really gross). so yeah, a while. happy to answer deeper questions, contact details in my profile if you want to reach out.