Even if I wanted to, I would not be able to design the most capable DAW. My central goal is to realize a microDAW that a musician can eventually know so well in a short period of time that it’s the first app they want to open when the desire to compose emerges. I also want that musician to be me.
The distinction between all-powerful and powerful has become increasingly important to me as SpaceAge™ has developed. Modern music software is extraordinarily capable, but capability and usability are not the same thing, and neither one guarantees intimacy. A conventional DAW can host tons of plugins, accommodate customized workflows, expose almost unlimited routing, and adapt itself to nearly every imaginable production philosophy.
That openness is truly useful, but it has a cost. The musician can spend a lifetime expanding the system without ever arriving at the point where the system itself feels fully understood. I want SpaceAge to move in the opposite direction: to offer enough possibilities to make almost anything, but few enough possibilities that a serious user can eventually understand the whole instrument.
The word “instrument” matters here. A piano is limited. A guitar is limited. A Yamaha DX7 is limited. A drum kit is limited. None of those limitations prevent enormous bodies of music from being created with them. Their boundaries are part of what allows musicians to form a deep relationship with them. A player can eventually stop thinking about where things are and start thinking almost entirely about what they want to hear.
That is the relationship I want SpaceAge to encourage—not to make the user continually aware of software architecture, available formats, plugin inventories, or tangent-inspiring workflows. The goal is to make the software familiar enough that it eventually becomes transparent for people who mainly want to write diatonic instrumentals using tried-and-true rock and pop arrangements.
SpaceAge already points in this direction because its basic conception is not that of a neutral container into which an unlimited number of unrelated tools are poured—at this moment, there is no plan to host third-party VST plugins inside it. It is a music-making environment with its own instruments, familiar sequencing concepts, its own drum-oriented tools, its own piano-roll and arranging workflow, its own mixer, its own effects, and its own ideas about how musical material should move from conception into a finished arrangement. The individual pieces are intended to belong to the same world, and that is more important to me than simply having a large feature count.
What are the benefits of a limited ecosystem?
A limited ecosystem does not mean a primitive ecosystem. In fact, I am interested in the opposite: considerable depth inside a deliberately bounded environment. SpaceAge contains subtractive synthesis, FM synthesis, wavetable synthesis, sampling, dedicated percussion synthesis, solid sequencing, modulation, automation, audio processing, and extensive sound design without needing all that to form an infinitely extensible general-purpose platform.
The crucial limitation is not how much music the system can make. The limitation is how many fundamentally different conceptual systems the musician is required to learn. That distinction changes how I think about adding features. If SpaceAge already has an instrument that can be extended coherently to cover new musical territory, I would rather deepen that instrument than create another nearly redundant one. If an existing effect can absorb a useful capability without becoming confusing, I would rather improve it than add another processor whose purpose overlaps substantially with something already present. If several parts of the application can share the same modulation behavior, preset conventions, editing gestures, or parameter logic, that consistency is preferable to allowing every module to invent its own language. I am not pursuing minimalism as decoration. I am pursuing conceptual economy.
The ideal is a system in which a relatively small number of important ideas recombine into a very large number of musical possibilities. That is how most great instruments work. The chromatic system gives us twelve pitch classes, yet those twelve notes have not prevented centuries of musical invention. A synthesizer may have only a handful of oscillator types, but modulation, filtering, articulation, performance, and interaction between parameters can create an enormous sonic space. A drum machine may have a finite number of voices, yet rhythm itself provides essentially inexhaustible variation. The same principle can operate at the level of an entire production environment. I would rather give a musician twenty concepts that interact deeply than two hundred concepts that remain largely unrelated.
Closed systems foster mastery
This is also why I see closed-system thinking as an advantage rather than an embarrassment. There is a tendency in software to treat extensibility as synonymous with seriousness. A “professional” application is expected to accept everything, route everything, host everything, and expose every conceivable option. But there is another path to seriousness: make the available tools good enough, varied enough, and interoperable enough that the user does not continually feel compelled to leave the environment. That is a much harder standard than simply providing plugin slots.
A genuinely successful limited ecosystem has to earn the right to be limited. If I remove arbitrary external choice, then the internal choices need to cover real musical territory. The synthesizers have to sound good, the drums have to be flexible, the effects have to cover useful processing needs, the sequencer has to allow sophisticated musical thought, the workflow has to remain fast when a project becomes substantial, and presets and sound libraries have to provide breadth without burying the user in meaningless abundance. And, a typical CPU has to cover the needs of the ecosystem. In a 1970s Jan Brady voice, we say, “Refactor, refactor, refactor!”
Closure without depth is merely restriction; closure with sufficient depth can become an instrument. My goal is not to prevent variety but to internalize it. Instead of asking the musician to assemble a production environment out of unrelated products, I want SpaceAge itself to contain a considered palette. Different instruments should have identifiable purposes. A dedicated drum synthesizer can do something a general synthesizer should not need to do elegantly. An FM instrument can occupy territory that subtractive synthesis reaches awkwardly. A wavetable instrument can provide spectral movement that another architecture does not naturally produce. Sampling can cover recorded reality and material that synthesis would be foolish to reproduce from first principles. The point is not to eliminate specialization. It is to prevent unnecessary duplication.
Every major component should justify its existence by adding genuinely new expressive territory. That gives me a useful test whenever I consider adding something to SpaceAge: does this enlarge the musical universe, or does it merely enlarge the menu? Those are not the same thing. A new instrument that opens an important synthesis method may substantially expand the system, while a fifth synthesizer that mostly recreates territory already covered by four existing instruments may contribute little beyond cognitive overhead.
Likewise, another compressor, another EQ, or another modulation effect is not automatically valuable simply because its algorithm differs. If the musician cannot articulate the musical reason for its existence, it probably does not deserve permanent space in the ecosystem. I had to face this dilemma myself. With a go-to delay, which I will leave unnamed, I looked through pages of features. Did I know what all those knobs and input fields actually did to a note? In this instance, I did not. Guilty as charged.
Complexity is a mental tax
Every addition has a carrying cost. It has to be designed, maintained, tested, documented, and remembered. More importantly, it occupies part of the user’s mental model, and I increasingly think of that mental model as a scarce resource. Musicians only have so much attention available while composing. Every time the application asks them to stop and remember where a function is located, decide between several almost identical tools, interpret an unfamiliar interface, or reconstruct how some subsystem works, a small amount of that attention is diverted away from actual music. The solution is not necessarily to remove sophistication. It is to make sophistication cumulative.
If I learn how modulation works in one part of SpaceAge, that knowledge should help me somewhere else in the app. If I understand how velocity is represented in one instrument, another instrument should not arbitrarily redefine the concept. If I automate a synthesizer, an effect, and a mixer parameter, the surrounding workflow should feel related. If I understand how presets are organized in one area, another area should not present an entirely foreign taxonomy.
Every hour spent learning SpaceAge should make more of SpaceAge understandable. That is one of the great weaknesses of an environment built from dozens of unrelated third-party products. Knowledge often fails to accumulate because the musician becomes competent with one synthesizer and then opens another synthesizer designed by another company with different terminology, different modulation conventions, different preset browsing, different scaling, different visual logic, and a different philosophy of interaction.
The user may own fifty instruments while knowing only a small fraction of each. I would rather create an environment in which the musician owns fewer conceptual instruments but knows them deeply. Depth eventually produces speed, speed eventually produces fluency, and fluency is where a tool starts disappearing between intention and result. That is the point I want SpaceAge to reach.
Was Alvin Toffler right about overchoice?
In Future Shock, Alvin Toffler coined the term “overchoice” to describe what happens once the number of options available to a person crosses from liberating into overwhelming. His argument was not that choice is bad, but that choice has a curve: a little of it increases freedom and satisfaction, and past a certain point, more of it starts producing anxiety, indecision, and a strange kind of paralysis instead. The chooser spends more energy comparing options than actually using any of them. I’ve written before about this exact dynamic in the home studio, under the related terms “option paralysis” and “analysis paralysis”: the producer who owns forty plugins and auditions them all before committing to any is not more free than the producer who owns four and knows what each one does. SpaceAge’s bounded ecosystem is, among other things, an attempt to design against overchoice from the start, rather than letting a musician discover it the hard way.
This philosophy also affects how I think about choice itself. Our software culture has trained us to assume that more choice means more freedom. Sometimes it does, but choice also has friction. If I own one excellent tool for a particular job, I can learn it. If I own twenty, each decision begins with an unnecessary preliminary decision about which tool to use. The larger ecosystem can produce a strange kind of creative poverty: a producer can possess almost unlimited options while repeatedly using only the shallowest layer of them. SpaceAge should instead encourage exploration downward. I want the user to discover that an instrument they thought they understood contains another level through fluency, and I want combinations between tools to reveal possibilities that are not obvious from looking at any single module.
I want mastery to be rewarded. A beginner should be able to get somewhere quickly, while an experienced user should be able to extract progressively more from the same environment. That means the system needs boundaries, but it also needs depth inside those boundaries. The ideal SpaceAge is finite when described and effectively enormous when played. A manual should, in principle, be able to explain the entire system. A dedicated user should, in principle, be able to learn every major instrument and effect and develop a mental map of the whole environment. But knowing the map should not mean exhausting the territory. I do not want users to spend twenty years merely discovering that another menu exists. I want them to spend twenty years discovering what they can do with the tools they already understand and publish music.
A shared vocabulary
There is a cultural advantage to this as well. When musicians share the same bounded environment, knowledge becomes transferable. Someone can discover an unusual technique in one SpaceAge instrument and another user can reproduce it because that instrument is part of their environment too.
Workflows become recognizable, certain tricks acquire names, presets become teaching objects, and experienced users can communicate efficiently because they share a vocabulary. That is how an ecosystem begins becoming a culture rather than merely a software product. Classic hardware instruments benefited enormously from this. People discovered techniques on MPCs, DX7s, Junos, trackers, samplers, and workstations and passed them around because everyone was working within the same constraints. There was enough stability for collective expertise to accumulate, and I want SpaceAge to have that property.
The pressure to keep adding
I also want SpaceAge to resist a common fate of mature software: permanent expansion for its own sake. Once a product exists for long enough, there is constant pressure to add. New features make good headlines, new modules create visible evidence of development, and a larger specification sheet is easy to market. Restraint is harder to demonstrate, but refusing unnecessary complexity is itself product development.
Improving SpaceAge should mean making an existing feature clearer. Sometimes it should mean consolidating two overlapping ideas. Sometimes it should mean refactoring the architecture so that several systems behave more consistently. Sometimes it should mean making an instrument deeper instead of adding another instrument. And sometimes the correct feature decision should simply be no.
Two tests for every feature
I want every major addition to pass two tests: it should materially increase what a musician can express, and it should do so without disproportionately increasing what the musician has to remember. A feature should earn its place once through capability and a second time through coherence. That principle gives the project boundaries without making those boundaries arbitrary. The goal is not austerity. It is concentration.
I want SpaceAge to contain enough synthesis to make an enormous range of sounds, enough sequencing to support genuinely sophisticated composition, enough effects to mix and transform those sounds, enough arranging power to finish real music, and enough specialized tools to give the environment its own character. But I want all of those things to feel like parts of one machine rather than a shopping mall of plugins or an operating system for other people’s music software. And, hey, SpaceAge itself ships as a VST plugin, not just the more philosophically grounded standalone system, so I’m not stopping anyone from bolting it onto another DAW if that’s what they really need from it.
If my goal is achieved, the limitations of SpaceAge will eventually become something closer to the physical laws of a musical world. The musician will know what exists and what does not. They will stop repeatedly evaluating the environment itself. Within those known boundaries they can concentrate on combinations, expression, and craft. That is ultimately what I mean by a limited ecosystem. I am not trying to reduce the number of things a musician can imagine. I am trying to reduce the number of things standing between imagination and execution.
I want enough possibilities that the system rarely dictates what kind of music must be made with it, but I also want few enough fundamental tools and concepts that someone can eventually say, with confidence, “I know this instrument.” At that point, the software no longer feels like a collection of features. It becomes a place the musician knows how to inhabit.
