By the middle of 2018, I had spent enough time working in notebooks that the next step was hard to miss: I needed interfaces.
Not a perfect app. Just enough GUI to stop treating every repeatable audio task like a miniature programming session. The notebook workflow had helped, but it only went so far. If a tool is going to be part of real work, it has to be simple to start, easy to run again, and less likely to let me fire off the wrong thing by accident.
So I started trying GUI frameworks.
I tried PyQt. I tried Kivy. Around this time I even built my first trivia game in Kivy, partly because games are a good way to learn how a framework thinks. You find out quickly how it handles screens, events, state, layout, and all the little details that are easy to ignore in a tutorial.
Kivy was interesting. PyQt was powerful. I still landed on Tkinter.
Why Tkinter won for that moment
Tkinter was not the sexiest answer. That may have been part of the appeal. It was available, direct, and good enough for the internal tools I needed. I was not trying to impress anyone with the interface. I was trying to make the audio process faster and less fragile.
That distinction matters. Internal tools don't need to feel like consumer software. They need to take hesitation out of the room and put the right controls in front of you, with the dangerous parts obvious so you can get back to the work.
Once I could wrap parts of the process in a small GUI, Audio Chop Shop started feeling less like an experiment and more like equipment. It was something I reached for. It became part of my day.
By then, Audio Chop Shop was moving into my regular client mixing workflow. Since then, there has probably never been a mix I have done that did not pass through one of the many tools I made. The tools got woven into how I work.
The tools earned trust by being used
This is the part I care about most. A tool becomes serious when it survives normal working pressure.
It is one thing to run a clean demo file through a processor and get a nice result. It is another to use the tool on a real client mix that has to keep moving, with imperfect audio, real delivery specs, a clock you can't slow down, and taste decisions still ahead of you.
The GUI experiments helped because they moved the code closer to muscle memory. I had less to remember. I would run the parts I trusted, listen, and keep going.
A lot of what Level Rebel is now traces back to that practical pressure. The product today is for people who don't want to become audio engineers to publish their podcast, a YouTube video, a course lesson, a short-form clip, or a founder update. They need the file to land correctly so the voice holds up on phones and laptops and the sound stops making the content feel amateur.
In 2018, I was still building for myself and for client work. The lesson was already there, though: good audio processing should feel like a dependable step in the workflow, not a mysterious ritual.
The current Level Rebel language talks about loudness, peak safety, dynamics, speech clarity, and a Sound Readiness Assessment. Those are cleaner names for things I had been dealing with in practical ways for years. Is the file too quiet? Are the peaks going to cause trouble? Will the voice disappear when someone hears the mix outside a studio?
The Tkinter era was not the final form. It was one of the first times the tools felt daily, and that matters. Daily use is where rough ideas get sanded down. Not because someone wrote a roadmap, but because the work keeps asking for the same fixes until you either build them or keep wasting time.
No comments yet. Be the first to comment!