Skip to content

Build in Public · 5 min read

The year the tool pile started acting like a product

By mid-2022, my private audio tools had multiplied, the GUI experiments were getting serious, and I was starting to move C++ ideas into Rust by hand.

By mid-2022, the audio tool situation had gotten a little out of hand.

I mean that mostly in the useful way. The tools worked, and they had become part of my daily mix process. I do not think there was a single mix I touched then that did not pass through one of the utilities I had built. Some handled one narrow job, while others covered bigger parts of the workflow. A few existed because I was tired of doing the same cleanup over and over and wanted the computer to stop making me babysit it.

The problem was that the tools had grown faster than the product thinking around them.

That is a weird spot to be in. Nobody keeps using useless tools for years, so the usage was a good sign. But private tools turn into a junk drawer fast. One button over here. One folder convention over there. A script that depends on me remembering the exact order of operations. A batch process with a name that made perfect sense on the day I wrote it and almost no sense six months later.

By 2022, I was trying to get that pile into a shape that felt less fragile.

The GUI search continued

I had already tried a bunch of GUI options over the years. Tkinter had been useful because it was simple and available. PyQt had more power, but it also brought more headaches with my system. Kivy was interesting, and I learned a lot from it, but it did not become the home for these tools.

Eventually, I landed on Python Gooey for a lot of the interface work.

Gooey made sense because I had many arg parse command-line utilities that needed just enough interface to be usable without turning every tool into a full application. A file picker, a few settings, a button, some output. That was enough for a lot of my work. I did not need a beautiful product screen yet. I needed something that reduced friction and helped me avoid mistakes when I was tired, busy, or moving between client projects.

This is one of those unglamorous steps that matters more than one would think. A decent wrapper can decide whether a tool actually gets used. If the interface makes the right path obvious, the tool becomes part of the routine. If the interface is annoying, I start bypassing it, and then the code might as well not exist.

The number of tools kept growing. That was exciting, and it was annoying. Every new tool solved a real problem, but it also added another thing to maintain. The project was stable in one sense: I trusted it with real work. It was not stable in the sense that a stranger could sit down, understand the system, and operate it without me explaining the odd little edges.

First Rust experiments

This was also when I started playing with Rust.

At first, Rust was not a clean rewrite plan. I was manually converting some of the C++ code into Rust to see how it felt. That is a slow way to learn, but it is also a practical one. You find out quickly which parts of your understanding are real and which parts you don't.

The C++ code had done its job. It had pushed parts of the audio processing to a lower-level shape. But some of it was rough. I had written enough of it to know what I wanted, and enough to know that I did not want to keep building the next version exactly that way.

Rust appealed to me because it forced a different kind of discipline. It made ownership and error handling harder to ignore. That could be frustrating, especially when I just wanted to hear whether a processing idea worked. But for code that might eventually outgrow my computer and my personal workflow, that friction started to look useful.

Manual conversion also showed me the architecture hidden inside the mess. When you translate code by hand, you have to ask what each part is really responsible for. Is this function doing audio math, file handling, naming, logging, and workflow policy all at once? If so, the language is not the real problem. The shape is.

I ran into that a lot.

Stable, but still mine

By the middle of 2022, the project had reached a funny stage. It was stable enough that I relied on it constantly. It was not a "product" that I would hand over to a creator and expect them to get value without me nearby.

That distinction still matters to me.

A tool can be powerful and still not be a product. My private audio workflow knew too much about me. It knew my folder habits, my naming habits, my tolerance for rough edges, and my willingness to rerun something if I did not like the output. A product has to be kinder than that. It has to assume the user does not know the backstory.

I was not there yet in 2022. But the project was less theoretical than it had ever been. There were enough tools, enough daily usage, and enough accumulated judgment in the workflow that I could start to see the outline of something larger.

The GUI experiments showed me where people would need control. The C++ work had made the performance and explicitness questions hard to ignore. Rust pointed at a cleaner core, provided I was willing to keep moving it forward one piece at a time.

It still looked messy from the outside. From the inside, it was real.

Comments (0)

Please log in to leave a comment.

No comments yet. Be the first to comment!