Philosophy

Some of the driving forces behind Monolith.

Let's start with the name. Some things come to mind. That black thing from 2001 space odyssey, perhaps?

The term "monolithic" comes to mind next. This term gets used a bit in the context of software engineering. This is indeed a monolithic repository of stuff. Instead of managing a bunch of little projects, I get them all to play together in one place.

I. Me. Mono. Singular. This is a project I built for myself. Artists have built their own tools for centuries. I try to capture that spirit by writing music software that I compose with. I don't expect others to really use this day to day. I do hope that people perhaps try it out and use components from this project for their own beautiful sound-making ecosystems.

Monolith, while centralized, also tries to be decoupled. Over time, I try to make it to decompose and have components be re-used and re-purposed for other projects. Environmentally friendly design call this "second life recycling". Usually applied to physical stuff, but it applies just fine to software too.

When you build music software from scratch, you will re-invent a lot of wheels. This provides the opportunity to question everything you thought you knew about computer-based workflows.

In truth, the name "Monolith" was so-named because it was originally to be integrated with the monome grid (formerly just reffered as the "monome"). It is the second iteration of it's kind. The first was an interactive graphical text editor called "monomer". This largely failed because making a useful text editor is hard.