Author on the Web, Render on the Machine

Two products in one runtime

SpaceMusic has quietly become two products that happen to share one engine. One is a live instrument — you perform with it in real time, and every millisecond matters. The other is a factory — it generates 3D geometry we export to Rhino and turn into 3D prints, laser-cut patterns, and sculptures, where nobody is watching the screen while it happens.

Most features clearly belong to one side or the other. The batch-export automation we're planning — run scenes, vary parameters, export the results in bulk — belongs squarely to the factory. And that single fact should decide where it lives. The reflex is "it's a SpaceMusic capability, so it goes into SpaceMusic." This memo argues the reflex is wrong: the part a person actually touches — designing a batch of exports — has no need for the engine, and folding it into SpaceMusic would burden a shared, live-performance control surface with a solo production tool. Build the authoring on the web platform; keep only the GPU-bound execution in SpaceMusic.

What the automation tool does

The tool takes one scene — a saved preset of parameters that SpaceMusic turns into generated geometry — and runs it many times while varying parameters, exporting each result. It is, in plain terms, a parameter-space explorer.

A sweep is the unit of that: pick a parameter and say how it should vary. Step a slider from one value to another in fifty steps. Or walk a dropdown through all of its options — every audio track, say. Add a second parameter and a real question appears: should the two move together (paired), or should the tool run every combination of them? The second choice multiplies — two dropdowns of ten each is a hundred exports, three is a thousand. The output is a pile of export files, one per run, that flow to a curation feed where the artist browses and picks favorites to take further.

We already built a working prototype of the authoring screen. It lets you stack parameters, choose paired-versus-every-combination, shows the running export count, warns when the number explodes, and previews the exact list of runs before you start. It did all of that in a browser, with mock data, touching no engine. That is the tell this whole memo turns on.

Where we already are

This tool is not landing on empty ground. Three of the pieces it needs already exist, and — importantly — already live on the web:

1. The library is cloud-backed. Scenes and their asset files (audio, objects, images) sync to cloud storage and are readable from anywhere.
2. The control surface is web-based and schema-driven. SpaceMusic's Pro UI is already a web app, and it renders itself from a generated file (spec.json) that describes every parameter — its type, its range, and its dropdown options.
3. The results feed is already a planned web platform. The place finished exports show up for review is being built on the web regardless of this decision.

So most of what the automation tool needs is already web-native. What is genuinely missing is small: the authoring app itself, a hand-off file, and an execution loop inside SpaceMusic.

Authoring is a file, not an engine

Here is the load-bearing idea. A batch is a G-code file. A CNC machine doesn't need the CAD program running in order to cut — it reads a file of instructions and executes them. The same split applies here. Designing a batch produces a list of commands: load this scene, set this parameter to this value, export, repeat. Producing that list needs data — which parameters exist, what values are valid — not a running engine. Only executing the list needs the machine.

Everything to the left of the seam runs anywhere — a laptop, a phone, a shared login. The only box that needs a graphics card is the worker on the right. The authoring app reads the cloud library, writes a .smbatch file, and is done; a SpaceMusic worker picks that file up, executes it on the machine, and pushes the finished artifacts to the feed — which loops the artist back to the authoring app to refine and go again.

Why the web, and not inside SpaceMusic

Four strands, each independently sufficient, together decisive.

1. The data authoring needs already lives on the web — often more accurately than in the engine

To design a sweep you need to know which parameters exist, what ranges they accept, and what options each dropdown offers. All of that is in spec.json, a file the web control surface already reads. A scene's actual saved values are in the cloud library. And for the file-backed dropdowns — which audio track, which object — the live list of choices is literally the contents of a cloud folder, which the web can read directly. The engine, by contrast, only remembers what was in that folder the moment the scene was saved. On the freshest data, the web is the better-informed of the two.

2. It doesn't belong in a shared, live-performance surface

SpaceMusic's control panel is used during shows. A batch-export queue — "run this scene 600 times overnight" — is the wrong tool in that room. It's a solo, back-office production task; putting its UI where a performer reaches for live controls clutters the instrument for no one's benefit.

3. On the platform it becomes a capability, not a bolt-on

Sitting on the web, next to the library and the feed, the tool closes a loop: author a batch, queue it, let a worker render it, review the results, pick favorites, refine, repeat. That is a coherent automation platform, reusing the cloud library, the schema, and the feed. Buried inside SpaceMusic it would be an isolated feature wired to none of that.

4. Web-first costs nothing later

SpaceMusic's own interface is web-based. So the very same authoring app can, if we ever want it, be embedded inside SpaceMusic's shell down the line — for free. We are not choosing the web instead of SpaceMusic. We are choosing where the tool is authored, and keeping every door open.

The one real seam: the contract

To be honest rather than tidy: "no dependency" is slightly too clean. The .smbatch file is a contract between two programs — the web author and the SpaceMusic worker — probably written by two people at two different times. G-code only works because both ends agree, precisely, on what each instruction means. Two details carry all the risk.

The value vocabulary. When the batch says audio file = track05, the worker has to resolve that to the exact internal choice it sets. If the web guesses a format the engine doesn't recognize, the engine quietly does nothing — and you get a batch of files that all used the wrong track, with no error anywhere. A silent, invisible failure. The fix: the contract must speak in terms both ends resolve identically — a library path, not an internal key.

Split validation. The web authors optimistically, from data that can be slightly stale; the worker validates at run time and tolerates gaps. That is fine — as long as the feed reports the skips. A run that silently drops a vanished parameter, with no note, is a pipeline that lies by omission.

"Define the batch file as a shared, versioned schema, with an owner, from day one. It is small — and it is the actual coupling."

Everything else that's genuinely hard lives entirely inside the worker and never touches authoring: a subtle timing gate (wait for the geometry to finish rebuilding before firing the export, so you don't capture the previous frame's mesh), and the plain fact that the worker must be an always-on machine with a GPU. Throughput there is digital-only — the physical printers meter out over days regardless. None of that is a reason to move authoring off the web; it's a reason to keep the two halves cleanly apart.

Why this matters

"The instrument and the factory want different tools. The mistake is building the factory's tools into the instrument."

This decision is really about which of SpaceMusic's two identities we are serving, and being disciplined about not blurring them. The live-performance work — smooth transitions between scenes, the real-time instrument — stays in SpaceMusic, because it is inseparable from the engine; that is a separate, larger project. The production work — bulk generation, export, curation — belongs on the platform, because it is inseparable from the cloud, the library, and the feed.

Keeping that line clean is what lets both halves get better without stepping on each other. And it quietly reframes the ask: this is not "a feature we bolt into SpaceMusic." Authored on the web, executed on the machine, feeding a curation platform, it is the front door of SpaceMusic as a production tool — the thing that turns a live instrument into a factory that also happens to perform in real time.

Glossary

Terms used in this document, in plain language.

Scene

A saved preset of parameters that SpaceMusic turns into generated geometry; browsed by thumbnail, stored in the cloud library.

Sweep

Running one scene repeatedly while varying one or more parameters, exporting each result.

Axis

One parameter being varied in a sweep, together with how it varies — a range of steps, or all of a dropdown's options.

Paired · Grid

Two ways to combine multiple axes: move them together (paired), or run every pairing (every combination / a grid), which multiplies the export count.

.smbatch

The proposed hand-off file — the list of instructions the authoring app writes and the SpaceMusic worker executes. The "G-code."

spec.json

The generated file describing every parameter (type, range, options); already read by the web control surface to render itself.

scene.json

A scene's saved parameter values, stored in the cloud library.

Cloud library

The cloud-backed store of scenes and asset files (audio, objects, images), synced across machines.

Worker

An instance of SpaceMusic running on a GPU machine whose only job is to execute batches and export artifacts.

Feed

The planned web surface where finished exports appear for the artist to review, pick favorites, and take further.

Rhino · .3dm

The CAD format SpaceMusic exports geometry to, for 3D printing and laser cutting.

Pro UI

SpaceMusic's web-based control surface.