For more than ten years, I've been building small music-related libraries and environments. Coming from the iconic sample-based workflow of Akai MPC, I've researched, tried and discarded many attempts at building the music programming environment where I would myself feel most at home in.
The story starts in 2014, with building a library called Bap to code beats with Javascript. At this point, I was still not enlightened and leaned fully into mutable objects and complicated connection graphs. While it may seem like a distant memory now, at that point in time, humans were still writing every single line of code by hand, and keeping the entire context window in their own memory.
My first deep dive into music programming focused mostly on encoding musical patterns as code with user interfaces borrowed from physical samples and drum machines. As in this example, the classic MPC pands and banks is transformed into a qwerty keyboard to interact with.
In the summer heat 2015, during a cross-country bus ride with broken air-condition, I had a revelation of how one would interact with my music programming libraries. Inspired and amazed by Type Drummer, I spent a weekend non-stop coding the first version, and the next few months iterating with a handful of passionate beta testers. The environment was a lot of fun to create small sample-based loops in, but I grew frustrated with the limitations of the DSL, and started sketching on a more comprehensive and flexible music programming language and environment.
One of the limitations of the 2015 version of trn.gl was that code was just static text, with no feedback about the sounds it produced at all. But solving the feedback problem was put to the side, in favor of going deeper with the programming surface itself: the syntax, the functions and the general concepts would have to be developed first.
In 2016, while working at Microsoft after the Wunderlist acquisition, I spent my evenings tinkering with different approaches to the environment and syntax.
I was conflicted between the simplicity of the 2015 version, and the ideal expressiveness I imagined my next environment to have. What is more important - that beginners can get started easily, or trading a higher learning curve for more power and flexibility? I am still searching for an answer to this question.
In 2017 I left the corporate grind and ended up spending a few months working hard on a version of trn.gl to release to the public. This was my goal, and I came quite far, until at the end of the year I decided to found a new company together with a group of friends from Wunderlist and Microsoft. Pitch was born, and for the next few years, little progress was made with my music programming.
In 2020 or 2021, I started building new experiments, this time focused on pattern manipulation in the spirit of TidalCycles.
Progress was slow, as my day job demanded most of the creativity and problem solving ability I had. But little did I know that this constraint was about to disappear...
Fast-forward to 2026. The world of programming has changed, radically. With expressive prompts, we can generate basic apps and complex user interfaces. "Writing code was never the hard part", they say, but for this personal side project, the ability to trade a few quick prompts for finished features with no manual effort has been life-changing, and has led to the newest iteration of trn.gl.
Feedback via highlighting chunks of code is back as a first-class primitive, and this version takes the familiar shape of a coding playground like CodePen or JSFiddle. Having processed many iterations of a similar concept, both actively in the foreground but also often passively and completely in the background, writing the next prompt is never hard.
The vision of what trn.gl should become feels effortless and inevitable.