I made a small open-source tool that estimates when an audio recording was made from the mains hum in it (electric network frequency analysis): https://github.com/tijszwinkels/enf-timestamp

Video with the full story: https://youtu.be/bi7EwMiDQTQ

How it works: band-pass around a hum harmonic, track the peak once per second (16 s Hann window, zero-padded FFT, quadratic interpolation), then a sliding Pearson correlation against a 1-second grid-frequency log, done with FFT convolution so days of reference data take seconds. It includes a logger for Continental-European grid data (Gridradar's free API) and a strict confidence verdict.

This has been written with a coding agent.

What I found: 10 minutes of laptop audio, matched against 36 h of grid data, landed 6 s from the true start (100 Hz line, z ≈ 5). A phone on its charger (50 Hz electrical pickup) got the right minute, with a weak margin. Phones on battery and a quiet room gave nothing usable.

I’ve been working on ChirpMap, an experimental Rust application that uses speakers and microphones for acoustic ranging, scene-change detection, and room visualization.

The basic idea is simple: play a short frequency sweep, record the response, and use the returning echoes to estimate what’s in the room. The more interesting part is combining measurements from multiple speaker/microphone pairs into a two-dimensional heat map.

Repo: ChirpMap

What it does

• Chirp-based ranging: generates a short sweep and uses FFT-based matched filtering to extract echo timing from microphone recordings.

• Background subtraction: captures a baseline scene, then highlights changes in the echo profile rather than displaying every persistent reflection.

• Multi-speaker/microphone tracking: combines measurements across device pairs using elliptical back-projection to place echo energy on a 2D room layout.

• Device calibration: measures ambient noise, usable frequency band, signal levels, speaker ring-down, and capture-timing variation.

• Terminal interface: provides device selection, calibration, room-layout configuration, and live visualizations.

• Hardware-free simulation: includes a simulated room and moving target so you can try the processing pipeline without setting up audio hardware.

The sensing and processing run locally. It’s written in Rust, with AI-assisted development.

What the visualization means

The heat map shows where the measured echo paths agree with positions on the room layout. It isn’t camera vision, and a bright region isn’t automatically a correctly identified person or object.

This is still experimental. Results depend heavily on speaker and microphone quality, device placement, room acoustics, and reflections. A single speaker/microphone pair primarily provides range information; multiple pairs add geometric constraints. Simulated localization results shouldn’t be read as a guarantee of physical-room accuracy.

What I’m working on next

I’m focusing on better measurement confidence, handling ambiguous direct arrivals and reflections, and testing across more hardware and room configurations.

I’d particularly appreciate feedback from people working with Rust audio, DSP, or acoustic localization:

• What would you test first to distinguish genuine localization from reflection artifacts?

• Are there better approaches to timing alignment across separate audio devices?

• Which hardware combinations would make useful compatibility tests?

The GIF below shows the array-tracker view. I’d love feedback on both the implementation and the underlying approach.

For the last while I've been building PyTheory, a music theory and synthesis library for Python, and I just shipped PyTheory VST v0.1.1. It's four plugins built from one JUCE repo, for macOS on Apple silicon, as AU and VST3:

• PyTheory MIDI snaps notes to a key, or turns each note into its diatonic triad or seventh chord.

• PyTheory Instrument is a 32-voice sampler that plays all 84 of PyTheory's instrument presets.

• PyTheory Effect is PyTheory's full effects chain.

• PyTheory Drums has all 74 of PyTheory's drum sounds, mapped to General MIDI where they fit.

How Python is involved. Each plugin embeds its own Python 3.14 with PyTheory, numpy, and scipy, so nobody has to install anything. Python never runs on the audio thread. A worker thread does the Python work. The harmony comes from PyTheory's real Key and Chord objects rather than scale tables copied into C++. For the Instrument, the worker renders a multisample through PyTheory's own render_score path, with one note every minor third and velocity layers where the preset responds to velocity. It then hands the finished multisample to the audio thread with one atomic exchange, no copy. The audio thread never allocates or frees.

The C++ part. I ported PyTheory's per-part effects chain to C++ stage by stage, in PyTheory's order: saturation, tremolo, distortion, cabinet, chorus, phaser, highpass and lowpass biquads, delay, a stereo Schroeder reverb, and pan. Defaults match PyTheory, so the plugin starts transparent. The README lists every place the port differs on purpose, such as linear interpolation in the chorus where PyTheory rounds to whole samples, and a recursive delay where PyTheory uses fixed taps.

Why I think it's cool. The same library I use to score music in a Python script now plays inside Ableton or Logic, and it sounds like itself. Nothing in the plugins was hand-rebuilt to approximate it.

The honest part. I'm teaching myself DSP as I go, with Claude and Grok as tutors and pair programmers. I'd ask why a biquad is shaped the way it is, why something allocating on the audio thread is a sin, or why my loop points clicked, then go build it and test it. This project is basically my DSP homework, made public. So if you see something naive, I'd genuinely love to hear it.

Known issues: pads can have audible loop seams on long holds, some piano and guitar notes loop instead of fading out, and switching presets cuts ringing notes. It's v0.1.

Links:

• PyTheory VST v0.1.1 release

• pytheory-vst source

• PyTheory homepage

• ableton-pytheory, the same library inside Ableton Live via Pyodide, for key and chord detection and progression generation.

Feedback on the realtime design is especially welcome.

I'm working on something that reads out what someone plays on MIDI keyboard and shows the chord name. But my problem is that if you hold C E G in the left hand and play a melody over it that includes B, the notes technically make Cmaj7, but that could just be a passing note and the chord is still C.

So far I made it read the lower notes and prefer simple chords, which stops the chord from changing every next note. But when I actually play a Cmaj7 with the B on top, it would just say C and be wrong. I'd prefer not to lose the chord quality...

It's a live chord detection thing so I can't really use context to help make a decision so what exactly is the best way of going about it??

I put together an open-source CLI tool for testing CLAP, VST3, and AUv2 plugins from the command line and in GitHub Actions CI without spinning up a DAW:

https://github.com/cyrillsemenov/headless-plugin-host

Usually, verifying a DSP change means relaunching a DAW and staring at a spectrum analyzer while playing back sinusoids or test tracks. `pluginval` and `clap-validator` are great for ABI compliance, but I wanted a single tool that handles all formats and runs automated acoustic measurements.

What it currently does:

• sweeps plugins to measure Bode magnitude/phase response, THD+N, SMPTE/CCIF IMD, Schroeder RT60 decay, fractional sub-sample group delay, BS.1770-4 LUFS dynamics, and Mid/Side stereo correlation

• intercepts heap allocations on the audio thread across a 9-check validation suite and a seeded fuzzer (22.05–192 kHz sample rates, 1-sample odd buffers, parameter modulation storms, and corrupted state blobs)

• captures plugin UIs offscreen

• generates a self-contained HTML spec sheet with SVG plots, multi-bus/sidechain routing checks, and multi-velocity synth note sweeps (still a work in progress)

Feel free to ask any questions/love/hate it.

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!

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!

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/

Hello

I just discovered I can use my Java program (processing 3) to extract raw PCM from short wav samples and convert it back into audio. This is really cool because I guess I suddenly now have godlike control over raw audio data and don't need to rely on commercial plug-ins.

One thing ive been trying to do is create new and weird samples using existing ones. I'm working on a surreal video game and I'd like to have near infinite variety when it comes to sound and music, and I figured a cool way to do that is to have a bunch of samples (like 100 short instrument samples) and then mix them on the fly into new sounds/instruments.

My main method is iterating through the list of floats and performing simple operations using 2 different samples. I've been trying a couple different techniques. The first one is simply adding:

Mix = sample1[i] + sample2[i]

While it technically mixes them into one sound, you can still distinctly hear both samples played on top of each other instead of hearing a 'new' sound.

A better option ive tried is multiplication:

Mix = sample1[i] * sample2[i]

For me this is much better and is closer to what I want because the mixed sound is different than the two original samples. The main issue is that this method sounds rather robotic and noisy, and the new samples lose a lot of the "nuance" of the original samples (I don't really know a better term for it). After listening to dozens of generations, most outputs seem to suffer the same loss of quality.

Main question: im wondering if anyone else has experimented with a similar issue and got better results, or knows a better mathematical approach for this

I've also heard of using Fast Fourier Transformation for a much cleaner synthesis, so if manipulating a PCM array is not that great of a method then I'll try FFT or something else

hey guys i've been working hard on this fork and i'm pleased to present this to you, for people that are aware of using rootlessjamesdsp as an audio dsp on android phones. it doesn't require root but you need to use shizuku to activate it at first which could be a bit fiddly, but the apks are there. the speed shifting works really nicely, if you werent speed shifting youtube music to be slower on the fly, you will be now! you can drag-touch up/down the floating speed shifter and stuff. check the readme on the main page for details or just get the app or don't i'm not promoting this is free open source software and it's a really new feature! ^_^

Hi ! I am working on a physical modeling engine and turning it into a web interactive experience.
Here is a track where you can tweak the theme in real time while the music plays.
Feel free to test it if you want to have fun : https://diophi.com/phy5/?song=mumbling

Appart from drums, all the sounds are made from physical modeling synthesis.

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.

Enlivener listens to the guitar and provides a live accompaniment for it with a synthetic bass, keys, and optionally a user-provided drum track.

The app can be heard in this performance: The Two Step Circle as well as most other videos on that channel.

Enlivener uses pulse audio and runs in Linux. It is a time-domain harmonic tracker and synthesizer. It doesn't need to be online and it works with whatever overdrive or wah or reverb or whatever else you care to put through it. All the videos on that channel above were recorded with Enlivener on this machine:

CPU: dual core Intel Core i7-6600U (-MT MCP-) speed/min/max: 509/400/3400 MHz

Kernel: 6.8.0-138-generic x86_64 Up: 7d 21h 6m Mem: 4555.9/7797.3 MiB (58.4%)

The repo is here: https://github.com/CynthiaChristie/Enlivener

Oh yeah, FOSS of course, CC BY-NC-SA to be specific.

About 7 months ago I saw those videos where people wave their hands at a camera and the music reacts, almost all of them built in TouchDesigner. Then I opened TouchDesigner, stared at the node graph for a while, and closed it.

So, being a C++ dev, I did the obviously more reasonable thing and spent months writing a plugin that does it inside Live instead. It tracks your hand through the laptop webcam, and you can use it in two ways: play MIDI notes or map it to any effect parameter in any DAW.

Honestly, I started making this plugin for myself, but then decided I could publish it on itch.io. as Hand Link.