Around 2012-ish, I started doing the thing that would eventually become a very long habit: writing little pieces of software to automate repetitive tasks.
There was no company idea and no product plan. The code was not clean or planned out. I was tired of doing the same technical chores while working on audio. If a task was repeatable and easy to mess up when I was moving fast, I wanted the computer to handle more of it.
That sounds obvious now. It did not feel obvious then. My professional identity was audio first. I composed, mixed, edited, and solved production workflow problems. Code was a side entrance into the same work. I was not trying to become a software founder. I was trying to get back to listening sooner.
The first tools were for me
The early apple scripts lived close to real sessions. They were the kind of tools you make because a file needs to be named correctly, checked, converted, measured, chopped up, or prepared before the actual creative work can continue. None of that is glamorous. It is also the stuff that quietly steals hours if you let it.
Audio work sits in a strange place between precision and feel. You need your ears, but you also need to track levels, formats, timing, filenames, exports, versions, and all the other details that can slow down a good day. I kept noticing that the machine was better than I was at the repetitive parts. So I gave it more of those parts.
Some of those early ideas were probably ugly. I am fine saying that because useful code (it was really scripting back then), is not always elegant code, especially when it starts as a personal tool. I was not trying to impress another developer. I was trying to remove friction from the audio work in front of me.
Putting code where I could find it again
In the following years, I had started putting code in places like GitHub and Bitbucket. That changed the relationship a little. A script on one machine is a scratchpad. A script in version control starts to feel like something you might come back to, improve, and trust on a real workday.
I was not thinking about open source in any grand way. Mostly, I did not want to lose things. I wanted history. If I changed a tool and broke it, I wanted a way back to the version that had worked during production.
That habit mattered more than I knew. Once code has history, you can see your own thinking change. You can see what kept coming back. You can see which annoying problems were not one time annoyances at all, but recurring workflow problems with a pattern underneath them.
In hindsight, this is where the future Level Rebel shape first shows up, even though I would not have called it that then. The core question was already there. How much audio cleanup and preparation can be made repeatable without taking the judgment away from a real mixer?
That is still the question. The audience, the interface, and the tools have all changed a lot since then. But the origin was very practical. I wanted to spend less time on mechanical preparation and more time making audio sound right.
I did not know yet that creators, podcasters, YouTubers, coaches, founders, and short-form video people would all run into many of the same problems at a different scale. I only knew that audio gets judged fast. A wrong level or a buried voice will land badly next to professional material, and people feel it immediately even when they cannot name the reason.
So this is the earliest part of the story. There was no startup behind it and nothing that looked like a launch. Just a working audio person slowly admitting that some of the best help in the room might be a script he wrote because he was annoyed the day before.
No comments yet. Be the first to comment!