By 2016, a lot of my audio tooling, an my passion for automated shortcuts, lived in IPython and then Jupyter notebooks.
The tools were not pretty. I would open a notebook, run cells, tweak settings, process the file, and keep listening until the result did what I needed. It was more of a working environment than a finished application.
But it worked.
The notebooks let me combine listening with measurement - in a data science-y way. I could open a file, process it, hear what changed, and run it again without wrapping the whole thing in a proper interface. For a working mixer, that was enough. A polished app could come later. I needed leverage.
Useful beat elegant
I have a soft spot for this stage because it was honest about what it was. The tools were awkward the way internal tools usually are. A notebook would have a few cells that made perfect sense to me and almost none to anyone else. Assumptions lived all over the place: file paths, default settings, the order you ran cells, the bits of process I kept in my head.
That is not how you ship software to customers. It is a good way to find out what keeps needing to be automated.
When you use a notebook once, it is an experiment. When you keep reopening it because it saves the day, it is asking to become a tool. That was the signal I cared about. I had built enough process around audio cleanup, prep, and level management that the code was not a novelty anymore. It had become part of the work.
Audio Chop Shop was already in there. It didn't have a name or an interface. What it had was a pattern: take audio that needs help, look at it, do the right things to it, and hand back something closer to publish-ready without burning a mixer's attention on the repetitive parts.
Why notebooks made sense
Jupyter was a good fit because the work was partly investigative. Audio processing is full of small decisions that are easier to make when you can see intermediate results. I could run a pass, listen, check values, and decide whether the next move was compression, level adjustment, cleanup, trimming, or something else entirely. Also, I was using notebooks extensively while learning machine, learning and data science.
A normal app hides that process. At this stage, hiding it would have been a mistake. I needed to see the gears. I needed to make bad assumptions visible. I needed to learn which steps were stable enough to automate and which ones still required my judgment.
There is a temptation, especially when you talk about software after the fact, to make every stage sound deliberate. You followed a plan that maps the structure, business logic, and scaling rules, and some people work that way. Not me. I have more of a hacker mindset, just start building and see what happens. This worked when I was solving the problems in front of me, and the shape came from doing the same work over and over.
By then, I was already moving toward ideas that still matter in Level Rebel: loudness that lands where the platform expects it, peaks that do not get a file rejected or turned down, dynamics that keep the voice present without squeezing the life out of the performance, and speech clarity that keeps people from reaching for the volume knob.
I would not have described it with the current product language then. There was no Score, no browser upload flow, no clean before-and-after report. There was a notebook, a file, a set of cells, and my ears.
Something I picked up in that stretch still holds: the first version of a useful tool should stay close to real work. Get too abstract and you end up solving imaginary problems. Polish it too early and you hide the fact that the core process is weak. The notebooks were rough, and not how I would do it today today, but they stayed close to the work.
Audio Chop Shop came later. Level Rebel came much later. The notebooks were the middle stage, where the idea stopped being a few scripts and started becoming a repeatable system. It was still held together by habits, cell order, and a lot of listening.
No comments yet. Be the first to comment!