1. Statement Of Purpose
Monolith is the name of a experimental music environment for computer music.
More to follow, I'm sure.
1.1. Principles
Before writing any code, I'd like to outline some core principles for this software. Software is nothing, if a set of choices. A good set of principles will help make good choices.
1.1.1. Preservation
Bitrot is the greatest threat to digital art preservation in this age. Many great works of art are written on very tall towers of abstractions and libraries. These moving parts make for very brittle infrastructures. Without constant maintenance and updates, software will become virtually unusable.
Art and music are based in tradition, whose body of work is maintained over generations. As composers, artists, and creators, we have a duty to add to that body of work for the next generation to learn and expand on. Computer-based art, being the adolescent medium it is, needs a way to be preserved for future generations to see. Otherwise, it will never grow and evolve as a medium.
How does one do this? In this day and age, I think it is a mostly futile goal to have full preservation of works forever. But one can make an attempt to preserve enough of it for a spell.
Some strategies:
Write the core DSP engine (called the DSP kernel) in ANSI C
Create a virtualization layer for all input/output access to the DSP kernel
Everything should have an offline component: offline rendering
Build an emulation package now: it is just as valid as "the real thing"
Text over binary, whenever possible
1.1.2. Mostly in-the-box, but who cares about that
Monolith is mostly software written for in-the-box music production. That is to say, most of the production happens with software inside the computer , rather than using on external hardware. This makes things very convenient (and ripe for Preservation). A sliver of the Monolith will be built upon specfic hardware, which my interest lies.
The key peripherals used in this setup will be the Monome grid controller, and the Griffin Knob. "Monolith" gets its name from the monolith 2001: a Space Odyssey. My monolith is my Monome. In many ways, the experience I had seeing the Monome for the first time was not unlike how the Apes saw monolith. To this day, I still ask myself: Why? Why the Monome? What do I see in this device? Why am I so fascinated by it? What made me throw hundreds of dollars at this thing?
The Griffin Knob was one of those devices I dreamed about: a single, continuous knob. It is a wonderfully built piece of hardware. And affordable too! The closest thing like it is the Arc controller (built by Monome), costing several hundred dollars more. In many ways, the Griffin Knob is a wonderful sidekick to the Monome.
1.1.3. Anti-DAW, Anti-Mouse
I have a thing against DAWs and Mice. I will explain why.
The contemporary Digital Audio Workstation has greatly stifled innovation for computer-based music production. Music software was originally written in a way that catered to a largely technophobic breed of audio engineers. They wrote the software interface to look like the analog tools they were used to. These skeumophoric design decisions are still prevalent in music software applications today. It is my opinion these designs, by their very nature of creature, do not and cannot fully leverage the full potential of computer-based systems. It is my interest to explore music creation systems which showcase the computer, not try to hide it or pretend it is something else. Not only do I think this approach will yield a more powerful system, but I also believe that better and more interesting music will be created as a result of this.
I don't like computer mice either. Monolith will avoid this. They were a wonderful innovation at the time, but they are clumsy and imprecise to work with. Click and drag is the bane of my existence. I much prefer a keyboard-driven workflow for my day-to-day computing needs. Capacitive touchscreens are a better solution to computer mice peripherals, though Monolith has no current intentions to explore this interface.
GUI-driven music applications make me a little nuts. We tend to fetishize GUIs a little too much in the CS world. Reactive GUIs change the way you hear your music. I find them a distraction. On top of that, they add enormous complexity overhead from an engineering standpoint. It is just not a cost I'm willing to pay.
1.1.4. Architects build Gardens
Here is a George RR Martin quote which describes an Architect and a Gardner:
“I think there are two types of writers, the architects and the gardeners. The architects plan everything ahead of time, like an architect building a house. They know how many rooms are going to be in the house, what kind of roof they're going to have, where the wires are going to run, what kind of plumbing there's going to be. They have the whole thing designed and blueprinted out before they even nail the first board up. The gardeners dig a hole, drop in a seed and water it. They kind of know what seed it is, they know if planted a fantasy seed or mystery seed or whatever. But as the plant comes up and they water it, they don't know how many branches it's going to have, they find out as it grows. And I'm much more a gardener than an architect.”
As a composer and sound designer, I like to assume the role of a gardner. As an engineer, I like to assume the role of an architect. Monolith is software for creative expression, so I get to play both roles. The goal of Monolith is to provide a garden for gardeners. However, the garden itself will be built by architects.
prev | home | next