By the summer of 2019, I had used my own audio tools long enough that client work and software work were starting to blur.
The tools started years earlier as practical things I needed for my own mixes. I was not trying to build a product. I was trying to get through real audio work faster without lowering the bar. A lot of that early work lived in IPython and then Jupyter notebooks. I would spin up a notebook, point it at audio, run a few cells, listen, tweak, and run it again.
That sounds clumsy because it was. It was also useful. Useful beats elegant when you are trying to finish a mix for a client.
By 2018, I had tried a pile of GUI experiments: PyQt, Kivy, Tkinter. I even built a trivia game in Kivy around that time, partly because I wanted to see how far I could push a Python interface. For the audio tools, Tkinter eventually won because it was boring and available. It gave me windows, buttons, progress indicators, file pickers, and a way back to the work. That mattered more than making something I wanted to show off.
But the audio code felt boxed in.
Python is great when you are still exploring. It lets you think in terms of the work itself: load this file, measure that loudness, split this section, normalize this pass, export that version. When the idea is still changing every day, Python is hard to beat. My problem was that some of the ideas had stopped changing. They were becoming part of my daily work.
When a tool becomes part of the day, the standards change. It has to be faster. It has to be more predictable. It has to fail less mysteriously. It has to handle larger files without making me wonder if I should go make coffee and hope the process is still alive when I come back.
Why C++ entered the picture
I did not wake up in the Summer 2019 with a clean architecture diagram or a plan to rewrite everything. Moving to C++ was smaller and messier than that. I started converting pieces.
Some of the Python code was fine, so I left it alone. Other parts were doing heavy work in ways that made sense in a notebook and less sense in something I used every day. Audio work exposes that quickly. A file is not an abstract object when you are waiting on it. It is minutes of sound, with sample rates, channels, peaks, fades, noise floors, and the details that decide whether the output feels professional or cheap.
C++ had two obvious advantages for me:
- It made the heavy processing feel closer to the machine. AKA Faster
- It forced me to be more explicit about what the code was doing.
That second point was uncomfortable. In Python, I could sometimes hide a bad idea behind a convenient library call or a flexible data structure. In C++, I had to look at the shape of the work more directly. What exactly is this buffer? Who owns it? How many samples are moving through this pass? What happens if the file is not what I expected?
I was not writing beautiful C++. I want to be honest about that. A lot of it was the kind of code you write when you are teaching yourself under pressure. It worked, then it got patched, then it worked again. I knew enough to be dangerous, and sometimes that is exactly what a solo tool needs in the early phase.
The tool was becoming real
The important change in 2019 was not the language. It was how I treated the tool.
Before that, the software felt like a set of personal shortcuts. After I started moving pieces to C++, it began to feel more like an engine. Still rough. Still private. Still full of decisions that made sense only because I was the only user. But it was no longer just a notebook with a few clever cells.
The working name around that era was Audio Chop Shop, which matched the internal mood of the thing at the time. It was practical and a little rough, a post-production utility that chopped, processed, cleaned, and prepared audio for real work. The name made sense inside my world, where the tool was built around my habits as a mixer.
Years later, that name would become a problem for a creator-facing product. But in 2019, I was not thinking about creators, subscriptions, landing pages, or onboarding flows. I was thinking about whether the next mix could be cleaner, faster, and more consistent because I had taught the computer to handle one more repetitive part of the process.
That is still how I trust tools. Not by what they promise. By whether they survive contact with actual work.
The C++ conversion was awkward, but I needed it. It made me separate experiments from infrastructure, and it exposed code I had been avoiding. It gave the project a stronger spine, even if I would end up rebuilding that spine later.
I did not know it then, but that summer was one of the first steps away from a personal utility and toward something that could eventually become Level Rebel. Not because C++ was the final answer. It was not. But because I had started treating the audio code like something worth hardening.
No comments yet. Be the first to comment!