Foley Field Notes: a tin box, an entire train

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

Foley Field Notes is a tiny imaginary sound studio. A tin box becomes a train; a cup becomes a bell; tracing paper becomes rain.

Pick a sound recipe, arrange its entrance in a scene, adjust its level, and download the result as a real WAV file. The sounds are synthesized in the browser. They are interpretations of everyday materials, not recordings of those materials.

The interesting part is what lives in Sanity. A recipe contains the instructions that make its sound: noise or tone layers, frequencies, attack, decay, gain and pulse count. A scene references those recipes with start times and levels. Content is doing something audible here.

Demo

Open Foley Field Notes

No login or microphone permission is needed for the player. A quick route through it:

1. Listen to Paper rain and Pocket train.
2. Choose The last train is a tin box from the scene selector.
3. Move the cup bell's entrance, change a cue's level, and play the scene.
4. Download the WAV. The arrangement stays in your current tab.

The editor is separate and requires Sanity project membership. Judges can use the public player and inspect the project ID/schema below; no editor credentials are published.

Code

Source, tests and build notes

The application is MIT licensed. The original sound recipes use deterministic synthesis rather than stock audio, so the repository includes the entire sound-generation path.

My Build Process

AI disclosure: this was an autonomous AI-assisted build using Codex under my direction. Codex implemented and tested the application and helped write this account. I am not claiming I manually wrote every line or personally performed subjective listening tests.

The brief used in the build was to make a small, unusual app where structured content materially changes the experience, with a working Astro frontend and no paid runtime AI API. The resulting scope was six sound recipes, two starter scenes, an editable cue sheet and WAV export.

The schema came before the cards

soundRecipe describes a material, a gesture, the synthesis layers and a duration. soundScene contains cue objects with references to recipes. A reused recipe is one document, not a copied block in each scene.

This choice is easy to see in the app: change a recipe's synthesis parameters in the editor, approve and publish it, then refresh the public collection. Every scene referencing it uses the new sound.

Approval had to describe the current content

A status field alone would allow a recipe to be approved and then silently changed. The workflow therefore stores a signature of the approved content. An edit makes that signature stale.

The Studio actions are Request review, Approve for playback, and Return to draft. The publish action stays disabled until the current recipe matches its approval. Workflow patches use revision checks so a concurrent edit cannot be silently overwritten. The frontend checks approval too.

This is an editorial workflow for trusted project members, not an administrator-proof permission system. The starting collection explicitly names its reviewer as Demonstration seed (automated); it does not imply human approval.

A few things needed correction

• The first test invocation failed before executing because the local environment could not spawn a child process. Running the same Node tests without process isolation fixed the runner issue without weakening the assertions.
• The volume control initially affected the next playback only. Review caught that mismatch; it now changes the active gain node as well.
• The initial Studio build command used an unsupported output flag. The current positional-output command built successfully.
• The first upload draft flattened nested file paths. It was discarded before committing, and the saved repository was checked for the proper src, tests and docs directories.

What was verified

Eleven automated tests passed for deterministic sound generation, non-silence, finite/bounded samples, cue timing, overlapping-cue normalization, WAV headers, invalid input and approval invalidation.

Browser checks exercised the actual public Sanity data, recipe selection, scene presets, cue editing, playback start/stop, WAV download and the empty state. Layout checks found no horizontal overflow at 320, 393, 768 and 1440 pixels in Chromium.

Four additional live Studio checks used a temporary unpublished document: a draft could not publish, requesting review enabled approval, approval enabled publication, and a title edit disabled publication again. The temporary draft was then removed.

The fallback is intentionally visible. If the initial content request fails, the player says Offline demonstration and loads its bundled sample pack. That is not reported as a successful Sanity connection.

Where I stopped

There is no runtime LLM, App SDK integration or automatic realtime refresh. The frontend uses an explicit Refresh collection control. Public users arrange sounds locally; they cannot write into the shared dataset. The tests do not establish subjective sound quality or compatibility with every physical device or assistive technology.

That left room to finish a small app whose structured content, review state and generated output all have a clear purpose.

Sanity Project Details

• Project ID: vkj2ioma
• Dataset: production (public)
• Document types: soundRecipe, soundScene
• Nested types: soundLayer, sceneCue
• Framework: Astro, with Sanity Studio for authoring

Inspect the schema or read the build notes.