Auto-Tune 3000: Learning Signal Processing by Building a Pitch Editor

Commercial audio tools can hide the mechanics. You drag a knob and a voice snaps into key, but the interesting part is what happened underneath. That curiosity was the reason this project existed.

Auto-Tune 3000 started as a way to understand pitch detection and manipulation by building something interactive enough to break. Not a polished plugin. A learning project that forced me into signal processing, UI state, and real time audio.

Building Around the Pitch Curve

The core idea was simple. Detect pitch, make it visible, and let a user reshape it. Once I had pitch points plotted over a spectrogram, the project became much more about interaction than audio theory.

The editing model was the part I spent the most time on. Selecting points, dragging groups, snapping notes to scales, then hearing the result during playback made the system feel alive.

• Pitch detection through YIN analysis and MIDI note conversion
• Frame by frame pitch shifting with overlap add reconstruction
• Interactive editing with scale snapping and undo redo state

The overlap add resynthesis was one of the first technical details that made me feel I was touching real DSP rather than stitching libraries together.

Where The Audio Work Got Interesting

Real time pitch shifting was harder than loading a file and processing it offline. Latency mattered. Artifacts mattered. Buffer handling mattered. The problem was not just shifting notes. It was doing it without the result sounding broken.

I learned a lot by hearing failures. Warbling audio taught me something. Glitches at frame boundaries taught me something. Audio is honest that way.

I also liked the scale quantization logic. It was small, but mapping detected notes onto musical constraints made the editor feel much more intentional.

What Was Rough

This was also clearly a learning project. Some code was duplicated. Global state in main.py became messy. There were imports and modules that reflected half refactors. Some comments were more chaotic than they should have been.

I would organize the architecture very differently now. I would unify state management, reduce globals, and separate DSP logic from UI code much earlier.

Performance could also improve. Graph redraws on mouse movement were not efficient. Stereo support was missing. File support was narrow. There was plenty unfinished.

What It Taught Me

One useful realization was that building tools teaches concepts differently than tutorials. Reading about pitch detection is one thing. Making detected notes draggable while preserving playback is another.

I also learned that user interaction can be as hard as algorithms. Multi point editing and undo logic caused as much complexity as signal processing.

For an early project, that mattered. It was one of the first times software felt like systems interacting instead of isolated functions.

What It Represented

This project was less about making an alternative to commercial auto tune and more about understanding the mechanics those tools hide.

Sometimes the right way to learn a system is to try building a rough one yourself.