Plantasonic

[Independent · 2026]

What should be built once and inherited, and what belongs to each product? Plantasonic is the shared layer under my creative work: tokens, themes, two engines, CLI scaffolds and an AI toolchain. The reference application proves the inheritance by being a real instrument. Try it live ↗

The Plantasonic live instrument running the Seed world: a full-frame field of blooming glyphs, the world browser on the left, sound parameters on the right, transport at the bottom

Product brief

One-off prototypes waste systems work. Every new study starts by rebuilding the same infrastructure: a token set, a shell, a theme, an audio graph, a renderer, a build. Plantasonic is the answer to that: a reusable foundation where a capability graduates into the shared layer only once more than one product needs it, and everything above stays product-shaped.

The rule that keeps it honest is a boundary, written down and enforced by dependency direction. The platform owns orchestration, tokens, themes, templates and the workflow. The engines own synthesis and rendering and nothing else. The applications own narrative, brand and behaviour. Nothing below reaches up, and nothing above forks what is below.

A platform that nobody uses is a folder of good intentions, so the platform ships with a reference application that consumes it in public: a living audiovisual instrument of five generative worlds, built from the same inheritance any other product would get.

The solution

01  /  05 1

One platform, three consumers

The platform is an SDK, not a starter kit you copy. Three things consume it: this reference application, which exists to test and demonstrate every capability in public; Signal 9 Live, the product application with its own narrative and identity; and whatever comes next, scaffolded from a template that already inherits the architecture. Each is developed, versioned and deployed independently. The platform never knows which application is running, and no application forks the platform to change it.

Platform Overview: Plantasonic described as an AI First Application Platform, with the list of what this reference application exists to test and demonstrate
02  /  05 2

What graduates

Ten capabilities are inherited rather than written: the design system, the active theme, shared components, the audio engine, the ASCII engine, the visual engine, the video slot, MIDI, AI services and the project templates. The test for graduation is simple and it is about count, not elegance: a second product needs it. Until then it stays in the product that needed it first. That rule is what keeps the shared layer from becoming a place to put everything.

The Applications inherit grid: design system, theme, shared components, audio engine, ASCII engine, visual engine, video engine, MIDI, AI services and templates, with version 0.4.0 and fifteen sections
03  /  05 3

Engines once

The sound engine and the ASCII engine are separate repositories with their own releases, consumed through platform adapters and registered as plugins the application can disable at runtime. Neither knows this application exists; neither contains a line of interface code. The application asks for sound and for glyphs and gets them, and when an engine ships a new version, every consumer of the platform gets it without a merge. Both engines have their own case studies on this site.

The ASCII Engine section: how the reference application consumes the engine through a platform adapter rather than a local fork
04  /  05 4

Themes above the system

Shared foundations should not flatten identity, so brand sits in a theme manifest above the token layer rather than inside it. Four slots are declared: Default, active here; Signal 9 and Plantasia, supported by the platform and deliberately not built in this application; and a reserved slot for what comes next. An application sets its theme in shell config and never hardcodes a hex value, which is what makes it possible for two products to look nothing alike and still share every component.

Theme System: Default active, Signal 9 and Plantasia supported by the platform but not built in this app, and a reserved Future Theme slot
05  /  05 5

The instrument as proof

The demonstration is not a marketing mock. Fifteen sections document the inheritance, and the last one launches a working instrument: five generative worlds, five sound levers, four visual parameters, five audio-reactive mappings, keyboard and MIDI performance, and projects you can save, export and import. It is meant to feel like cultivating an ecosystem rather than programming a machine, which is also the fastest way to find out whether the platform underneath actually holds.

The Flow world running: spiralling glyph currents across the full stage with the instrument surfaces floating above

Build the system once.
Every product
inherits it.

By the numbers

The Applications inherit grid of platform capabilities

1

platform, owning tokens, themes, adapters, templates and the workflow

3

consumers: this reference app, Signal 9 Live, and anything scaffolded next

5

generative worlds in the instrument, each a sound and visual preset bundle

My role

I set the platform-versus-product cutoff and wrote it down as enforceable boundaries, designed the token and theme manifest layers so brand sits above the shared system, specified the engine adapters and the plugin surface, designed the Creative Workspace layout the instrument runs on, authored the five worlds, and built the reference application that demonstrates all of it. Six repositories, one dependency direction.

Role

Product Designer, Systems Architect

Timeframe

2025 to 2026

Disciplines

Design Systems, Platform Architecture, Creative Tools

Current state

Platform foundation complete at v0.12.0; the reference application at v0.4.0, live. The instrument runs on the design system's Creative Workspace layout, with both engine plugins registered and toggleable at runtime. All five worlds run indefinitely as of the engine fix on 25 September 2026; what that fix exposed is written up below rather than hidden.

Stack

TypeScript, Vite, Bootstrap 5, Web Audio, Canvas, Web MIDI

Repositories

Platform SDK, design system, sound engine, ASCII engine, reference app, product app

The platform overview loads first: work down the sidebar to see what an application inherits, then open Live Instrument. Pick a world from the browser on the left and press play. Sound needs a click before the browser will let it start, so the first press is what starts the audio.

Push the sound levers while it runs: growth and bloom change the density of the field, because the visual engine is listening to the audio. Switch worlds without stopping and the instrument crossfades both halves at once. Turn a plugin off in the inspector and watch that half of the instrument stop without taking the other half with it.

Problems & decisions

Decide what gets built once, prove it by consuming it, and keep every product's identity above the line.

Each creative study I started began the same way: a token set, an application shell, an audio graph, a renderer, a build pipeline, a deploy. The work that carried between them was infrastructure, and rebuilding it every time meant every prototype was a little worse than the last one could have been. Worse, fixes stayed local: a scheduling bug fixed in one synth never reached the other. The cost was not the first build, it was the fifth.

Ownership is written down per repository, as what it owns and what it explicitly does not. The platform owns runtime orchestration, tokens, themes, templates and the AI workflow, and does not own narrative, brand or game logic. The engines own synthesis and rendering, and do not own interface, runtime or presets at the application level. The applications own the experience and do not own engine logic or token definitions. A capability graduates into the shared layer when a second product needs it, and not before; until then it stays where it was born.

The sound engine and the ASCII engine are separate repositories, consumed as versioned dependencies through platform adapters and surfaced as plugins with their own lifecycle. The application asks the platform for sound and for glyphs; it never reaches into an engine, and no engine knows an application exists. The alternative, which this replaced, was vendoring: a copy of the design system lived inside the reference app, seventy-four thousand lines of it, and every fix had to be made twice. Both engines now have their own case studies here, which is the clearest proof the boundary is real.

A shared system that flattens every product into the same look is a failure, so identity lives in a theme manifest that sits above the tokens rather than in them. Four slots are declared: Default, active in the reference app; Signal 9 and Plantasia, supported by the platform and deliberately unbuilt here; and one reserved. An application declares its theme in shell config and is forbidden from hardcoding hex values, which is the rule that makes the separation hold in practice rather than in principle. Theme preference is restored before first paint so nothing flashes.

There is a documented toolchain from design to deployed application: Figma as the source of truth, the Figma MCP server carrying design context into the tooling, the design system as the layer that decides what the tokens and components actually are, and rapid UI generation against those patterns as the last step rather than the first. Repositories export AI context files so an assistant starts with the architecture instead of guessing it. Generation accelerates exploration and documentation; the boundaries between repositories stay human-led, because that decision is the whole product.

Plantasia came first: an interface concept drawn from plant sonification and ambient music culture, favouring calm generative visuals over dense controls. It was the calm counterweight to my denser interface work, and it let the visual system lead. Almost everything in Plantasonic is downstream of it: the sound engine carries the name, the levers are growth, bloom, roots, mold and bacteria rather than oscillators and filters, the worlds are ecologies rather than patches, and the instrument is meant to feel like cultivating something evolving instead of programming a machine. Plantasia survives as a theme slot the platform supports.

  • Six repositories with one dependency direction: the platform SDK and its templates, the design system, the sound engine, the ASCII engine, this reference application, and Signal 9 Live as the product application. TypeScript and Vite throughout.
  • The design system ships tokens, a Bootstrap 5 theme, an application shell and the Creative Workspace: an overlay-first layout where the stage fills the frame and the transport, preset browser, inspector and status HUD float above it at named anchors, with presets for visualizer, installation, presentation, studio and performance modes.
  • Engines arrive through platform adapters registered as plugins, each declaring its contributions and able to be disabled at runtime without taking the rest of the instrument down.
  • Quality gates as scripts rather than good intentions: a thin-app architecture guard that fails if the application starts owning what the platform owns, plus integration, platform, design-SDK, preset and visual-language checks before ship.

Capturing this page found two bugs and fixed one of each kind. Mold and Nebula, the two glitch-heavy worlds, used to render for about two seconds and then go black while the status HUD still read Visual running: the ASCII engine's canvas renderer built an alpha bucket index that could come out NaN, and indexing the bucket array with it threw. The engine now ignores non-finite input, guards the bucket, and stabilises the simulation that was generating the NaN, so all five worlds run indefinitely. What the fix exposed is that something still sends NaN in: the engine logs one warning naming the control (density, strength and glitchAmount), which points at the platform's visual adapter passing audio levels through before the analyser has data. The values are now ignored instead of fatal, and the real fix belongs in the adapter.

The rest stands as is. The preset browser lists Seed twice. Below roughly a thousand pixels of viewport height the status HUD overlaps the inspector, because one is anchored top-right and the other centre-right with no collision rule between them. Signal 9 and Plantasia are theme slots the platform supports, not themes built in this application. And one fix was made here rather than only reported: the reference app had stopped importing the Creative Workspace stylesheet when the vendored design system was replaced by the real dependency, which collapsed the instrument stage to a strip and scattered its floating panels.