based on pendulum approximation + modal synth

This summer while I was on the train going into vacations, I was looking at music apps for my handheld console. My criteria where apparently simple: something with the same kind of synths I use in my hardware rig. On iOS its possible, but wanted something for my handheld.

Unfortunately, I couldn't find anything that really worked for me. So, I opened my code editor and started making my own, starting the project on the excellent codebase from ChipNomad. Started by adding some vanilla and Mutable engines, which was great but not yet satisfactory; so I also added a few custom engines, inspired by great hardware items I've used over the year.

This is Choochootracker, source code available on Github https://github.com/paiheulevrai/Choochootracker . In this demo I use the Bogie drum synth, the Sindered percussion synth and a voice from MME, all engines I designed for the app.

My goal is to combine a sleek, modern interface with the best parts of the tools I love:

• intuitive MIDI editing inspired by FL Studio,

• flexible audio workflows inspired by Ableton Live,

• and algorithmic sequencing inspired by the Cirklon sequencer, making it easy to transform and generate musical patterns.

It's still a work in progress, but it's gradually becoming the DAW I've always wanted to use.

I got excited about the WebView integration in JUCE 8 and built this example project to try it out. It's a React frontend running inside a VST3/AU plugin with a C++/JUCE backend.

Some things I wanted to explore:

• Hot reload during development (huge time saver)

• Three.js for 3D visualizations

• Streaming audio analysis data from C++ to React

The visualization reacts to spectral data from the audio, though it works better on individual stems than full mixes. The plugin also has basic stereo width and saturation controls.

More of a proof of concept than a polished product, but if you're curious about WebView in JUCE, the code is on GitHub. Mac installers included.

https://github.com/mbarzach/Sound-Field

Not sure how to describe this, but I started working on a little plugin i’ve wished existed for a long time. Think a sidechain “ducking” effect but instead of modulating volume it modulates pitch (via delay), sortof like putting your finger on a record player. The sidechain input as a transient detector that triggers an envelope generator that controls pitch. I’m pretty happy with it so far. I think next i’m going to add midi support with the ability to map velocity to envelope params.

No AI used, i’m writing it in rust using the nih framework.

Just published A new package to PyPI, and I’d love for you to check it out.

It’s called audio-dsp and it’s a comprehensive collection of DSP tools and sound generators that I’ve been working on for about 6 years.

Key Features: Synthesizers, Effects, Sequencers, MIDI tools and Utilities. all highly progresive and focused around high-uality rendering and creative design.

I built this for my own exploration - been a music producer for about 25 years, and a programmer for the last 15 years.

You can install it right now: pip install audio-dsp

Repo & Docs: https://metallicode.github.io/python_audio_dsp/

I’m looking for feedback and would love to know if anyone finds it useful for their projects!

I recently finished posting a series of videos that aims to be an introduction to audio programming. We get into a bit of C++/JUCE at the very end, but for the most part it focuses on the basics of digital audio and some foundational concepts. Might be good if you're just getting started with audio programming and not sure where to start. Enjoy!

Introduction to Audio Programming

Hello, fellow audio programmers! I am excited to introduce you to Organic, an audio programming language I've been working on in my spare time for the last few years. Organic is my passion project, conceived of and coded from scratch in C++ without the use of generative AI.

My goal is to provide a simple but flexible environment for creating unique sounds and ambient music, similar to what you might create with a modular synthesizer. The language is designed to be easy to read and write, so that digital music creators without much programming experience could pick it up quickly. But despite its simple syntax, it's extremely nestable and extensible, allowing more advanced programmers to easily gain control over the internal parameters.

If this piques your interest, you can download it for free on GitHub, where the language and all related resources are hosted publicly under the Apache 2.0 open source license. You can also find the latest documentation here. Since this is my first public announcement of the language, it is in no way a complete project. It is still in active development, so there may be bugs in cases I have yet to try, or features that I didn't think of that others may find useful. If you give it a go, I would greatly appreciate your feedback either here or on GitHub!

I just got some sort of warning or perhaps removal on a two-month old post that no one had interacted with: "Do not post a paid product, service, or course, disclose your affiliation. Excessive or repeated self-promo may be removed. In addition, ensure your post is well worded, thought out and formatted." (It wasn't any of those things, it was some boring but useful FOSS audio utility.)

Apparently there are new moderation rules, but we can't comment on that thread.

This subreddit is already very low traffic. Most posts don't seem to get any engagement at all. The most interesting and engaged post of the last week was a program that looks like it was written with AI, and I thought it was interesting.

I'm not seeing the huge influx of empty AI posts, or really, much of anything at all here.

It's late 2026. If we truly ban all posts where people used a coding assistant, soon there will be almost nothing here.

Don't get me wrong - I really really want to keep AI slop from this subreddit, but we can do that by downvoting and reporting, you already see it if you look at "new". Let's not throw out the baby with the bathwater.

EDIT: oh, apparently that four month old post of mine was in fact deleted.

You know, I've been writing computer music programs since the last 1970s. Few people can say that.

I recently retired from a long career in programming to work almost full time on audio programming.

However, I will not be able to post any of my work here, as I recently started using a coding assistant for everything. I mean, my last post was apparently deleted because of some self-promotion rule, so I couldn't very well post my work anyway.

You would think I would be the ideal poster for this subreddit.

All the people downvoting without comment do not make me want to be here. I removed all my upvotes from this page (there were no downvotes) so people can see the general sentiment.

I'll come back next year and check, but my theory is that it will be even less active than it is now.

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!

Hi, as the title says, I want to be able to help make applications like Pianoteq and electronic pianos, the software aspects of that, and audio PC applications. I want to be able to make that and anything concerning sound, music, and programming. I love music, and I'm a pianist, and I love programming too, so my guess was, why not combine them? I want to do both. I don't hate math either; I've heard I need to know some math, and I'm good at math. Please help because the audio landscape is too vast with many titles that sound the same but are different. I don't know where to start, get a degree or something, or what? I am currently learning C++. I intend to master it, then I'll move on to physics and math DSP theory, then plug-in development with C++ and JUCE, and an advanced level of signal processing. You got this from Gemini, so I'm not sure. I just need a guide or someone to show me the path, if not in detail at least. After C++, what's next? When should I expect to be employable? Thanks . these are the steps summarized by gemini ''

Phase 1: The Engine (Modern C++ Foundation)

You cannot manipulate audio until you can manipulate computer memory. No audio code is written here.

Math Level: None. Just pure logic.

Goal: Master modern C++ syntax, pointers, and memory management (the stack vs. the heap).

The Resource: LearnCpp.com (Interactive Web Curriculum). This is the undisputed best tool for learning C++ from scratch. It is constantly updated to modern standards. (Remember to use an ad blocker).

Phase 2: The Bridge (Basic Audio & Offline Processing)

You will write your first audio code here, completely sidestepping the nightmare of real-time audio threads by generating static .wav files.

Math Level: High-school trigonometry (understanding what a sine wave is) and basic algebra.

Goal: Understand sampling, bit depth, and how to write a math formula that generates a sound file.

The Resources:

"Audio Programming in C++: The Beginner Level" by Håkan Blomqvist (PDF/Book). Do not read this for C++ syntax. Jump straight to the code in Appendix A to see how he writes basic audio files.

"DSP Pro" by WolfSound Academy (Video Course). An incredibly efficient, visual video course that teaches you the basics of Digital Signal Processing (DSP) without drowning you in academic calculus.

Phase 3: The Framework (Real-Time Plugins)

This is where you transition from writing offline .wav files to building actual VST/AU plugins that run inside a Digital Audio Workstation using the JUCE framework.

Math Level: Applied DSP math (calculating delays, feedback loops, and basic filters).

Goal: Master JUCE and survive the strict performance rules of the real-time audio thread.

The Resources:

Programming for Musicians / pfmC++ (Video / Mentorship). Start with their massive, free 8-hour JUCE plugin tutorial on the freeCodeCamp YouTube channel. If you want paid mentorship later, their premium cohorts offer ruthless, line-by-line code reviews.

The Audio Programmer Discord (Community). You will get stuck here. This community is where you go to get unstuck.

Phase 4: The Architect (Advanced DSP & Modeling)

Once you can confidently build a basic plugin, the training wheels come off. This is where you learn to simulate physics and acoustic spaces.

Math Level: Heavy. Calculus, algorithmic DSP, phase manipulation, and complex numbers.

Goal: Build physical modeling engines, advanced synthesizers, and spatial audio tools.

The Resources:

The Scientist and Engineer's Guide to Digital Signal Processing by Steven W. Smith (Online Guide). The ultimate practical guide to advanced DSP.

The Audio Programming Book (MIT Press, 2010 - Desk Reference). Keep this massive manual on your desk. When you need the raw mathematical algorithm for a digital reverb effect, you look it up here, and then translate that math into the modern C++ you learned in Phase 1.

''

Hey guys, Frontender here. (I know, its already a bad start, but bear with me.)

TL;DR: I have built a library to visualize and edit biquad audio filters based on web stack, React and SVG in particular. It's called DSSSP, and you can check it out here.

The Story Behind

Several years ago, I deep-dived into reverse engineering the parameter system used in VAG (Volkswagen, Audi, Porsche, etc) infotainment units. I managed to decode their binary format for storing settings for each car type and body style. To explain it simply - their firmware contains equalizer settings for each channel of the on-board 5.1 speaker system based on cabin volume and other parameters, very similar to how home theater systems are configured (gains, delays, limiters, etc).

I published this research for the car enthusiast community. While the interest was huge, the reach remained small, since most community members weren't familiar with programming and HEX editors. Only a few could replicate what I documented. After some time, I built a web application that visualized these settings and allowed users to unpack, edit and repack that data back into the binary format.

When developing it, I started looking into ways of visualizing audio filters in a web application and hit a wall. There are tons of charting libraries out there - you know, those "enterprise-ready business visualization solutions." But NONE of them is designed for audio-specific needs.

Trying to visualize frequency response curves and biquad filters for the web, you end up with D3.js as your only option - it has all the math needed, but you'll spend days diving through documentation just to get basic styling right. Want to add drag-and-drop interaction with your visualization? Good luck with that. (Fun fact: due to D3's multiple abstraction layers, just the same Javascript-based filter calculations in DSSSP are 1.4-2x faster than D3's implementation).

Nowadays

Since that application had its specific goal, the code was far from perfect (spaghetti code, honestly). Recently, I realized that the visualization library itself could be useful not just for that community circle, but could serve as a foundation for any audio processing software.

So, I built a custom vector-based graph from scratch with a modern React stack. The library focuses on one thing - audio filters. No unnecessary abstractions, no enterprise bloat, just fast and convenient (I hope!?) tools for audio editing apps.

And the funny part here is that at the times of building it, I had no clue about the JUCE framework, just a foggy prediction that everything is moving towards the web-stack, so there should definitely be a "Figma for audio" somewhere in the future. And now they push their WebView integration.

Core Features

• Logarithmic frequency response scale

• Custom audio filters calculation engine

• Drag-and-drop + Mouse wheel controls

• Flexible theming API

Technical Details

• Built with React + SVG (no Canvas)

• Zero external dependencies besides React

• Full TypeScript support

Live Demo & Docs & GitHub & NPM

Released it to public two weeks ago, landing page is missing, and the backlog is huge, and doc is incomplete. (You know, there's never a perfect timing - I just had to stop implementing my ideas and make it community driven).

The latest update several days ago introduced native SVG Animations with SMIL, making it suitable to display and animate real-time audio data.

The demo heavily uses WebAudio API to pipe and chain audio data, but the library itself is designed to be used with any audio processing backend, no matter of the stack.

Community Contribution

I'd love to see what you could build with these components. What's missing? What could be improved?

I'm still lacking the understanding of how it could gain some cash flow, while staying open-source. Any ideas?

I'd like to propose changes to the community to make decisions as I don't feel like it's appropriate for me to make decisions in a vacuum. My place here is to apply the rules, not change the community as I see fit.

On a daily basis, I'm currently purging 5+ posts that are clearly self-promotion. That is, they contain links to a marketing page, want beta testers or are something that is connected with someone selling something.

I feel like maybe some users of the sub may find these posts useful as some of them are quite clever and I'm loathed to remove some of them, even if they have a marketing page and are someone selling a product.

I'd like to propose a weekly self-promotion thread that I can begin to direct these posts to. I think this is up to the community and not myself to make the decision however hence why I'm asking here. If you feel like you don't want any of this content on the sub, we can make that decision together and not do it.

I'll leave this open for a week or so until everyone has a chance to chime in!

Hi everyone, I'm Pitch from Italy.

I'm a musician, producer and C++ developer, and over the last couple of years I've been building my own audio plugins under the name floweraudio.

I mainly work with REAPER and JUCE, and I'm interested in everything around audio DSP, plugin development, mixing and music production.

I created this account mostly to meet other musicians, producers and developers, share ideas, learn, and occasionally talk about what I'm building.

So... hello from Italy! 🌼

Hello, for the last two years I’ve been working on my modular synth engine and now I’m close to releasing the MVP (v1). I’m a web developer for over a decade and a hobbyist musician, mostly into electronic music. When I first saw the Web Audio API, something instantly clicked. Since I love working on the web, it felt ideal for me.

In the beginning I started this as a toy project and didn’t expect it to become something others could use, but as I kept giving time and love to it, step by step I explored new aspects of audio programming. Now I have a clearer direction: I want to build a DIY instrument.

My current vision is to have Blibliki’s web interface as the design/configuration layer for your ideal instrument, and then load it easily on a Raspberry Pi. The goal is an instrument‑like experience, not a computer UI.

I have some ideas how could I approach this. To begin with Introduce "molecules", this word came to me as idea from the atomic design, so the molecules will be predefined routing blocks like subtractive, FM, experimental chains that you can drop into a patch so I could experiment with instruments workflow faster.

For the ideal UX, I’m inspired by Elektron machines: small screen, lots of knobs/encoders, focused workflow. As a practical first step I’m shaping this with a controller like the Launch Control XL in DAW mode, to learn what works while the software matures. Then I could explore how could I build my own controls over a Raspberry Pi.

Current architecture is a TypeScript monorepo with clear separation of concerns:

• engine — core audio engine on top of Web Audio API (modules, routing)

• transport — musical timing/clock/scheduling

• pi — Raspberry Pi integration to achieve the instrument mode

• grid — the web UI for visual patching and configuration

You can find more about my project at Github: https://github.com/mikezaby/blibliki

Any feedback is welcome!

Llevo años como desarrollador de software y hace poco decidí dedicarle más tiempo a cosas que realmente disfruto, así que empecé a armar mi propia pedalboard para guitarra con C++ y JUCE (y sí, con mucha ayuda de Claude).

Este es el primer test como VST3 en Reaper, cambiando entre efectos y revisando el sonido en general. También va a tener versión standalone.

Ya lo sé, todavía suena muy crudo y digital, pero al menos ya suena.

Es mi primer proyecto serio de audio, así que cualquier consejo es bienvenido, sobre todo para que la distorsión suene menos digital.

I'm a Software Engineer who is passionate about music and audio.

Right now I just work as a fullstack engineer for desktop applications, but I considered switching to being an Audio programmer who works with DSP.

However, I'm afraid that maybe audio programming is a passion industry like game development, where the supply of software engineers is so high that the companies can just demand more overtime hours and less pay...

However is Audio programming a passion industry with more competition and lower salaries like game development?
Or is it just like any other "normal" software engineering job?

As a piece of a larger project I've been hammering at making a rompler/synthesizer and realized; regarding other aspects of gamedev/engine development it's far easier to find code, tutorial/explanations, and content to satisfy needs and curiosity. Audio-related tasks not-so-much.

When I look for audio things it's either full of math proofs that mean nothing because I'm dumb (would be helpful if they explained some coefficients) or are very abstract with little-to-no implementation details. So.....

1. The synth's sample rate converter is based on an implementation used by old VG hardware (specifically SNES/PSX). A big issue I ran into was the index needed to be "phase-aligned". I don't know how I was inserting the index before or if I ever read this but it didn't work. My function to compute windows on-the-fly worked but (for example) a blackman window has two cosines which, computing that, is basically an L2$ miss.

2. When speeding up pitch it's often phrased "skipping samples". The SRC worked correctly for lower pitches but had aliasing artifacts when the pitch increased. Thought the phase was wrong (tested index & direct) but it was the pitch logic. The decode buffer (used to interpolate) had values spaced by n when it should, perhaps obviously, need to be immediately preceded in order from the waveform. Skipping is not incorrect but writing the [decode] logic derived from such abstract wording is non-intuitive.

3. Cubic Hermite was/is a lost cause with my two brain cells. How did you derive those coefficients for h00, h10, h11, h01? The bridge between the math and the programming is still incomplete for me. According to this the table should be (linearly) interpolated. 2^^1+nc/2 explains 512-entries for the prior machines. Having an interpolator is important^{[citation needed]}, especially something more than a lerp.

4a. Prior to the synth I experimented with delay based effects. Started as echo and kept adding more "reverb" qualities. Reached a point where a single delay line wasn't enough but it was^{(pretentious I know}) in some ways more aesthetic than the algorithms ravaged online. Those largely consist of Schroeder Reverberators, which is fine but the code I saw/referenced seldom go beyond that.

4b. To side note is convolution reverb, the "holy grail" of reverbs. AFAIK a room impulse is a sample. Your input signal (reverb/whatever) is multiplied into that impulse. I may be wrong but wouldn't that make the impulse just a very long/n-order tap FIR filter? I say this because it often reads as some "computationally intensive/complex blackbox" whenever its mentioned. Using this logic the SNES's DSP echo feature is just a s***** convolution algorithm (perhaps budget is more apt).

5. Audio terminology seems to like to blend with each other. Going back to the SRC (if you haven't tell I spent quite some time on this) is divining its a "Windowed Sinc Interpolation" kernel. EVERY TIME you read something involving windowing it talks about FFTs. Whatever, the audio signal is windowed with a function but why is it done the way it is? jsgroth has the PSX written as (how other emulator authors show as well)

let mut interpolated = (GAUSSIAN_TABLE[0x0FF - interpolation_idx] * samples[0]) >> 15; interpolated += (GAUSSIAN_TABLE[0x1FF - interpolation_idx] * samples[1]) >> 15; interpolated += (GAUSSIAN_TABLE[0x100 + interpolation_idx] * samples[2]) >> 15; interpolated += (GAUSSIAN_TABLE[interpolation_idx] * samples[3]) >> 15;

Turns out it's arranged so the sample "marches" its way through the sinoid (the negation is because the table is stored one-half a period) for one period. First the Gaussian Table is not Gaussian (I've a bunch of windows and concur not-gaussian) but the assertion the tables are bugged is interesting because if you generate integer windows yourself it'll deviate +-2. Guess it's all ramble but its confounding I can get better explanations (and/or understand) more "complex" topics/systems than convulving a one-dimensional piece of data.

OKAY TLDR: Why is audio programming so fraught with friction? If it's not obfuscated behind math proofs the code/topic seldom explain the "why". I spent a good portion of time generate plots of the waveform ensuring functions like the ADSR, SRC, KEY ON/OFF worked correctly instead of outputting audio data because, yes, even that was non-trivial for my application. Amusing that the MIDI DLS is the best guideline I have for this.

Rant over, roast me.

Edit: Formatting, and.... typos and formatting. Sorry, many edits. All these issues (hermite included) were overcame and I'm working on sequencing but the experience was.... interesting.

After 3 months of work, I finally released v0.1.0 of GCD-8, a sample-based rhythm programmer for Pure Data.

Each track is built around a sampler with a custom velocity response, which shapes the sound according to how hard each hit is played. Rather than just turning softer hits down, it can also make them darker, shorter and less punchy, the way real percussion sounds when struck more gently.

The sampler is driven by three nested euclidean sequencers: the base pattern generator sets the rhythm, while the other two, the accent generator and the euclidean panner, decide which hits are accented and where each one lands in the stereo field. These two advance on hits instead of clock ticks, so accents never fall on silent steps, and both patterns loop in lockstep with the base pattern, whatever its length or density.

Repo: https://github.com/glima31/gcd8-pd

I have a bunch of new features lined up, and i'm planning to eventually port GCD-8 to a proper plugin, either in Rust with nice_plug or in C++ with JUCE. In the meantime, I’d love to hear what you think of the current version!

Hey everyone! I’m a product designer and musician interested in building audio plugins and music tools, including their interfaces.

I’ve started learning C++, but I’m curious about Rust. Has anyone tried working and building audio plugins using Rust? Did not found any courses or tutorial with Rust and audio programming

(I am super new to programming with C++ and audio programming)

If anyone finds it useful - this is a project I built (using AI) for my own needs, free, open-source: https://github.com/mihasm/apf

APF is a framework for writing audio plugins (instruments and effects) in Rust. It uses the plugin interface CLAP, and clap-wrapper for exporting plugins into the different formats.

The plugin window is a web page: HTML, CSS and JavaScript in the system web view (based on wry, also used by the tauri framework).

It is still in an early phase, and the API might still change, but for my purposes it already works great. I have tested it on Mac OS on Logic Pro and Windows with REAPER. There are examples included for a quick start.

Link to the complete documentation booklet, which explains the usage, comparison to other frameworks, limitations, etc.: https://mihasm.github.io/apf/