Source confidence: medium
See also: Deeper Dive — The Album Is a Device Again — Offline Generative Music Objects →

The Album Is a Device Again — Offline Generative Music Objects

Insight class: Creative Fusion · Difficulty: Hard · Quality: 3/5 Connected entries: 9 · Tools: After Effects, Anthropic, Apple Shortcuts, Blender, Claude, FFmpeg, Grok Imagine, Hermes Skills Hub, Khaen, Kimi, Moonshine, Muse Code, Next.js, OpenAI, Pocket TTS, Python, Raspberry Pi, Raspberry Pi 5, Sharp Memory Display, TypeScript, kimi-k3-in-c

In short: Produces a song-as-object prototype: a Raspberry Pi player that recombines the artist's own 8-12 stems by seeded rules so no two plays match, adds an optional local voice line, shows the play number on a Sharp memory LCD, and sits in a printed case with a priced bill of materials (BOM).

Key fact Detail
What it covers hardware, music, video production, 3D
Tools After Effects, Anthropic, Apple Shortcuts, Blender, Claude
Posts covered 9 posts (1 S-tier, 5 A-tier) · top: Gemma Translator — offline speech translation… · Claude Opus 5.5 to Blender — 3D animation… · Tristan Perich's 1-Bit Symphony — music from…
Creators @byjackprice, @dailyhistoryclips, @drcintas
Sources dated Mar 2026 – Oct 2026
Difficulty Hard
Prompt system Run-it-yourself prompts
Last verified 2026-10-22

Thesis

Tristan Perich already shipped a symphony as a chip in a CD case. Google's Gemma Translator shows a full speech model stack running offline on a Pi 5 with a printable case and parts list. Local voice cloning fits in 100M parameters, and memory LCDs sip power. Put those together and a song can be a small object that performs a slightly different take every time it plays — the artist's own voice and stems, recombined on device, forever, with no server.

Why it matters

Musicians get a physical edition that streaming can't flatten — each object unique, each play unrepeatable — at a bill of materials a small run can carry. It turns a release back into something you own instead of license.

The evidence — connected entries

Tristan Perich's 1-Bit Symphony — music from on/off pulses on a chip

Creator: @egapmada · Tier: A

Precedent — a composition housed as a chip in a CD case; code as score, object as release

1-Bit Symphony is a composition housed in a CD case: a microchip running assembly code that outputs 1-bit on/off pulses as sound. A 695-page companion book prints the processor's cycles for the first hundredth of a second.

View original post

Gemma Translator — offline speech translation on a Raspberry Pi 5

Creator: @itsnicconley · Tier: S Tools: Moonshine, Raspberry Pi 5

Hardware recipe — full offline model pipeline on a Pi 5 with BOM and printable STL case

Google open-sourced Gemma Translator: Moonshine for speech recognition, Gemma for translation and a TTS model for voice, all on a Raspberry Pi 5 with no network at ~7 tokens/sec, enough for live Spanish–Mandarin conversation. Repo includes code, parts list (battery, touchscreen, speaker, micro keyboard with language knob), deployment script and printable STL case.

View original post

AI weekly roundup — Pocket TTS, Hermes Skills Hub, Kimi K3 in pure C

Creator: @drcintas · Tier: A Tools: Anthropic, Grok Imagine, Hermes Skills Hub, Kimi, Muse Code, OpenAI, Pocket TTS, kimi-k3-in-c

Audio models — 100M-parameter local voice cloning and CPU-only model streaming

Six releases: Kyutai Pocket TTS (100M-param local voice cloning, 6x real-time), Nous Research Hermes Skills Hub (90k agent skills), Grok Imagine Image 2.0 regional editing, Meta Muse Code terminal agent with parallel worktrees, Qwen3.8-Max (2.4T MoE, 1M context), and kimi-k3-in-c, a 176KB C99 engine streaming experts from disk to run a 2T model with no GPU.

View original post

Sharp Memory Display — per-pixel memory LCD for low-power hardware

Creator: @mewtru · Tier: B Tools: Sharp Memory Display

Display — near-zero-power memory LCD for liner notes or a live score that changes per play

Sharp memory displays store each pixel's state, so they only need a tiny maintenance signal. That makes them near e-paper in power, reflective for sunlight readability, yet fast enough for ~50fps, as on the Playdate.

View original post

NFC stickers + vibe-coded web app — physical taps that log real-life habits

Creator: @byjackprice · Tier: B Tools: Apple Shortcuts, Next.js, Raspberry Pi, TypeScript

Interaction — NFC taps as physical triggers to pick movements or moods

Programmable NFC stickers on a water bottle trigger an Apple Shortcut that logs each finished bottle to a tiny Next.js/TypeScript web app, surfaced as a home-screen widget. Part two of an IRL vibe-coding series; next step is a Raspberry Pi force sensor to log automatically.

View original post

Y-Pan — 3D-printed panoramic 35mm camera instead of a $5k XPan

Creator: @plumsojuyang · Tier: A

Proof that printed enclosures plus open CAD and a BOM make a credible product

A maker designed the Y-Pan, a 3D-printed panoramic film camera reproducing the Hasselblad XPan's wide 35mm format. Everything except the lens is printed, parts cost about $100, it builds in about a week, and the CAD files and bill of materials are on the creator's site.

View original post

The khaen — Lao bamboo free-reed organ that plays on inhale and exhale

Creator: @pop.music.culture · Tier: A Tools: Khaen

Musical material — drone and free-reed textures that stay musical under recombination

Explainer on the khaen from Laos and Isan: bamboo pipes with metal free reeds, played by both blowing and drawing breath like a harmonica, so it can sustain continuous sound and simple chords. Its buzzing, hypnotic tone now shows up in electronic and ambient music.

View original post

Glenn Gould's humming — thinking music away from the piano

Creator: @dailyhistoryclips · Tier: B

Philosophy — Gould's humming: the performance artifact becomes the signature

Glenn Gould hummed audibly on nearly every recording despite Columbia engineers' mic tricks. He traced it to practising under a vacuum cleaner's noise, which taught him to hear pieces internally and learn away from the instrument; the voice is the overflow, audible on the Goldberg Variations.

View original post

Claude Opus 5.5 to Blender — 3D animation built entirely as code

Creator: @nateherkai · Tier: A Tools: After Effects, Blender, Claude, FFmpeg, Python

Audio and SFX generated as code, the same move applied inside the object

Claude Opus 5.5 wrote everything: a web mock of the After Effects UI, a Python script that builds the Blender scene, the character animation, plus the music and sound effects. Blender rendered 360 frames on GPU in about 15 minutes and FFmpeg stitched the video. Full prompt is comment-gated.

View original post

Action sketch — how to implement this

Prototype on a Pi Zero 2 or Pi 5: a Python player that recombines 8–12 stems of one song by seeded rules (order, mutes, tempo drift) so no two plays match; no ML yet Add a local voice layer — Pocket TTS or a small cloned-voice model speaking or singing a variable spoken-word line — plus a memory LCD showing the play number and today's arrangement Print 10 cases from the Gemma Translator STL as a base, price the run, and pre-sell to existing listeners Falsifier: if listeners in a blind test prefer the fixed studio take every time, or the BOM forces a price above what 10 fans will pay, the format is a curio

Prerequisites

Key tools and resources

Creators to follow

Prompt system — run this yourself

Everything below is pasteable into Claude Code, Claude, or any agent. Use the one-shot when you want the whole result in one run; use the step prompts when you want to steer. Every step carries its own audit, and the gap audit at the end makes the agent find and fill what it missed.

Mission. Produces a song-as-object prototype: a Raspberry Pi player that recombines the artist's own 8-12 stems by seeded rules so no two plays match, adds an optional local voice line, shows the play number on a Sharp memory LCD, and sits in a printed case with a priced bill of materials (BOM). For a musician with stems and a small listener base. Done means 1,000 logged plays with no duplicate arrangement or clipping, measured battery runtime, a blind test against the studio take, and a pre-sale result above BOM cost.

1 · Deeper, not bigger

Before running anything, make the task deeper rather than larger. Ask: what would a top professional do here that I am not asking for; what is the rawest material; which methods and tools; what, other than the model or me, proves it right. Then ask for exactly that.

Rewritten prompt — ask for exactly that:

I want to release one song as an offline object that plays a different arrangement every time. Act as a generative composer and embedded engineer. Read the raw sources first: my stems, the Gemma Translator repo, Kyutai's Pocket TTS model card, a Sharp memory LCD datasheet. Then: (1) build a stem compatibility matrix and a variation grammar (order, mutes, tempo drift within +/-3%, fixed key) and justify every rule musically; (2) write a Python player for Pi Zero 2 W and Pi 5 that renders a seeded arrangement, normalizes to -14 LUFS with true peak at or below -1 dBTP, and logs a SHA-256 of every arrangement; (3) test whether Pocket TTS runs fast enough on each Pi, and if not, fall back to a pre-rendered bank of voice lines; (4) drive a Sharp memory LCD showing play number and today's arrangement; (5) adapt the Gemma Translator case and price a 10-unit BOM. Prove it with a 1,000-play soak log, measured battery runtime and a blind test against the studio master. List every claim you could not verify. Clone no voice without written consent.

2 · One-shot prompt

ROLE AND STANCE
You are a generative-music engineer building a one-song hardware edition: a Raspberry Pi object that performs the artist's own stems in a different arrangement each play, with no network. You are skeptical of every speed and size claim in the source posts and you measure instead of repeating them.

CONTEXT
- Precedent: Tristan Perich's 1-Bit Symphony, a composition shipped as a chip in a CD case. Code is the score; the object is the release.
- Hardware recipe: Google's Gemma Translator runs Moonshine, Gemma and a TTS voice offline on a Pi 5 at about 7 tokens per second; the repo ships code, parts list, deployment script and STL case.
- Voice: Kyutai Pocket TTS, claimed 100M parameters, local voice cloning, 6x real time, one-command setup, on a desktop, not a Pi.
- Display: Sharp memory LCDs hold pixel state, near e-paper power, about 50 fps on the Playdate.
- NFC stickers as one-tap triggers (byjackprice); the Y-Pan's open CAD plus BOM as product proof; khaen drones as recombination-safe material; Gould's humming as a signature artifact.
- User inputs: 8-12 stems, a target price, which Pi boards they own.

HARD CONSTRAINTS
- Offline at runtime. No API calls, no telemetry.
- Every arrangement is reproducible from (device_id, play_number) and logged as a SHA-256 of its JSON.
- Integrated loudness -14 LUFS +/-1, true peak at or below -1 dBTP, for every render.
- Tempo drift limited to +/-3% and pitch never shifted.
- Voice cloning only of the artist's own voice with written consent stored in the repo; check the Pocket TTS licence before shipping.
- The SD card must survive a yanked battery: read-only root, counter written atomically.

DELIVERABLES, IN ORDER
1. claims.md: each creator claim with its test.
2. grammar.yaml: stem roles, compatibility matrix, mute, order and tempo rules, a musical reason per rule.
3. player/: Python package with render(seed), play(), tests and a systemd unit.
4. bench.md: render time, boot-to-sound, current draw, Pocket TTS real-time factor, per Pi.
5. voice/: on-device TTS or a pre-rendered bank of 50+ lines selected by seed.
6. display/ and nfc/: memory LCD showing play number and arrangement glyph; NFC tags mapped to moods.
7. case/ plus BOM.csv at quantity 10 and minimum price at 2.5x BOM.
8. soak_report.md: 1,000 renders, hash uniqueness, loudness, underruns.
9. listening_protocol.md: blind test, 20+ listeners, against the studio master.

GAP ANALYSIS (BUILT IN)
Write gaps.md: claim or requirement, status (verified / unverified / false), evidence. Cover at least Pocket TTS speed on the actual Pi, whether it can sing, Zero 2 W RAM headroom with 12 stems, STL fit for your DAC and speaker, the LCD VCOM toggle, and rights to stems and voice. Fill what you can by measurement now; for the rest name the missing hardware or permission.

SELF-QUESTIONS BEFORE STOPPING
- Does the sparsest legal arrangement sound like the song or like a fault?
- Can different seeds sound identical despite different hashes?
- Does any rule run out of variety by play 10,000?
- Is the variation audible in the first 20 seconds?
- Would a fan pay the computed price, and what is the evidence?

STOP CONDITIONS
Stop and report if the stems are not time-aligned, if no consent exists for voice cloning, or if the minimum price exceeds the user's target by more than 50%. Otherwise stop when all nine deliverables exist and gaps.md is complete.

RETURN FORMAT
A short summary table: deliverable, path, status. Then the bench numbers, the soak results, the minimum price, and the top five open gaps from gaps.md.

3 · Step-by-step prompts

Step 1 — Ground truth: stems, repos, claims

Goal: Inventory the raw material and turn every creator claim into a test.

You are preparing a generative hardware edition of one song. Do not write player code yet.
1. Inspect the stem folder the user provides. For each WAV report sample rate, bit depth, channels, duration in samples, peak dBFS and integrated LUFS (pyloudnorm). Fail the step if lengths differ by more than one sample or sample rates differ; ask the user for a re-export instead of resampling silently.
2. Clone the Gemma Translator repository Google published. Record the exact parts list, the deployment script's model downloads and sizes, and the STL file names and bounding boxes (use trimesh to print extents in mm).
3. Read Kyutai's Pocket TTS repository and model card. Record licence, supported hardware, whether voice cloning needs a reference clip and how long, and whether singing is supported at all.
4. Fetch the datasheet for the Sharp memory LCD you plan to use and note resolution, interface (SPI), the VCOM/EXTCOMIN toggle requirement and current draw.
5. Write claims.md quoting each creator claim with a test: '~7 tokens a second' (Gemma Translator), '6 times faster than real time ... literally one command' (Pocket TTS), 'up to 50 frames per second' (memory display), 'about $100 ... in a week' (Y-Pan cost benchmark).

Expect: stems_report.csv with one row per stem, repo_notes.md for Gemma Translator and Pocket TTS, display_notes.md, claims.md with at least 6 claims each paired with a concrete test.

Audit before moving on: Recompute LUFS on two random stems to confirm the report. Every claim needs a numeric pass/fail threshold. If the Pocket TTS licence forbids commercial use or says nothing about ARM, mark the voice layer at-risk now.

Step 2 — Variation grammar

Goal: Define the musical rules that make every arrangement different and still the song.

Using stems_report.csv, write grammar.yaml for this song.
- Assign each stem a role: identity (must always play, for example lead vocal or main hook), structural (drums, bass), colour (pads, drones, effects), ornament.
- Write a compatibility matrix: pairs that clash (two competing leads), pairs that must co-occur (a kick and its sub layer).
- Define section order rules using the session's bar markers: which sections may be repeated, dropped or swapped, and which order is fixed (the ending stays the ending).
- Define a tempo drift range no wider than +/-3% and forbid pitch change.
- If the song has drone or chord material, treat it like a khaen: sustained free-reed layers that can enter and leave without breaking harmony; give them wider mute probability.
- Add one 'signature artifact' rule in the spirit of Glenn Gould's humming: a quiet, varying human element (a breath, a count-in, a studio murmur stem) that appears in some plays and becomes the edition's fingerprint.
For every rule write a one-line musical reason. Then compute the size of the arrangement space by brute-force enumeration or a combinatorial formula and report it. Target at least 10,000 distinct legal arrangements.

Expect: grammar.yaml with roles, matrix, order rules, tempo range and reasons; space_size.md giving the count and the method used.

Audit before moving on: Table the 20 sparsest legal arrangements. Any missing an identity stem or holding a clash pair means the grammar is wrong; fix and re-count. Under 10,000, loosen ornament rules first.

Step 3 — Seeded player and soak test

Goal: Ship a deterministic, gapless, loudness-safe renderer with no ML.

Write a Python package player/ that implements the grammar from grammar.yaml.
- render(device_id: str, play_number: int) -> (np.ndarray, dict): seeds numpy.random.Generator(PCG64) from SHA-256 of f'{device_id}:{play_number}', samples a legal arrangement, mixes stems in float32, applies tempo drift with the rubberband CLI or pyrubberband, normalizes to -14 LUFS with pyloudnorm, applies a true-peak limiter to -1 dBTP, and returns audio plus the arrangement dict.
- arrangement_hash = SHA-256 of the canonical JSON of the arrangement dict.
- play(): reads the counter from /data/counter (atomic write: temp file, fsync, rename), renders, streams to sounddevice with a block size that does not underrun, increments the counter only after playback starts.
- Log one JSON line per play: play_number, hash, LUFS, true peak, render_ms, underruns.
- tests/: determinism (same inputs give byte-identical output), grammar legality on 500 random seeds, counter survives a simulated crash mid-write.
Then run a soak: render plays 1-1000 without audio output and write soak_report.md with duplicate hash count, LUFS min/max, true-peak max and render time p50/p95.

Expect: player/ package with passing pytest, soak.log of 1,000 lines, soak_report.md showing 0 duplicates, LUFS within -15 to -13, true peak at or below -1.0 dBTP.

Audit before moving on: Run pytest and paste the summary. Grep soak.log for any true peak above -1.0 or LUFS outside range; any hit fails the step. Listen to plays 1, 2, 500 and the sparsest seed found; if two sound identical by ear despite different hashes, add a perceptual distance rule (minimum number of changed stems between consecutive plays).

Step 4 — Pi bench and power budget

Goal: Measure the player on real hardware and pick the board.

Deploy player/ to Raspberry Pi OS Lite on each board you have (Pi Zero 2 W, Pi 5). Use a systemd unit with Restart=on-failure and enable the overlay filesystem via raspi-config so the root is read-only, with a small writable /data partition for the counter.
Measure and write bench.md:
- boot-to-first-sound in seconds (phone stopwatch, 5 runs, median)
- render time for a full arrangement, p50 and p95 over 20 plays
- peak RSS memory with all stems loaded (use /usr/bin/time -v); on the Zero 2 W's 512 MB, test whether stems must be streamed from disk instead of held in RAM
- current draw at idle, during render and during playback with a USB power meter, then runtime estimates for the battery in the Gemma Translator parts list
- audio path: I2S DAC HAT or USB DAC, checked with a recorded 1 kHz tone for hum
If render time exceeds the first section's length, pre-render the next play in the background.

Expect: bench.md with a table per board, a recommended board and audio path.

Audit before moving on: Pull power during playback 10 times; any SD corruption or counter reset fails. Compute runtime from measured mA, not marketing capacity.

Step 5 — Voice layer: on-device or pre-rendered

Goal: Add a variable spoken or sung line without breaking the offline promise.

Get written consent from the artist for cloning their voice and store it as consent.md. Install Kyutai Pocket TTS on the chosen Pi following its own README, and measure real-time factor for a 10-second line at the default settings. Compare against the claim of 6x faster than real time.
- If RTF is at or below 0.5 on the Pi, integrate on-device generation: a text grammar of 20-50 fragments (dates, play number, lines from the lyric sheet) assembled by the same seed, synthesized during the previous play.
- If RTF is worse, or the board runs out of RAM, pre-render a bank of at least 50 voice lines on a desktop with the same model and ship them as WAV, selected by seed.
- Pocket TTS is a speech model. Test singing explicitly; if it cannot hold pitch, use speech only, or record the artist singing short variants instead.
Place the voice by grammar rule (for example over the intro drone), duck colour stems 3 dB under it, re-normalize.

Expect: voice/ (on-device integration or WAV bank), voice_bench.md with measured RTF, consent.md.

Audit before moving on: Any of 10 placements that clips, cuts mid-word or masks the identity stem fails. Re-run the soak with voice on.

Step 6 — Display, NFC and case

Goal: Make the object legible and touchable, and price it.

Display: wire the Sharp memory LCD over SPI, use Adafruit Blinka with adafruit-circuitpython-sharpmemorydisplay, and toggle VCOM per the datasheet. Show the play number, the date and a compact glyph of the arrangement (one column per stem, filled if playing). Update only at play start to keep power near zero.
NFC: add a PN532 breakout, read tag UIDs with nfcpy or the Adafruit PN532 library, and map 3-5 tags to grammar presets (mood, movement, 'drone only'). Ship the tags as printed cards.
Case: start from the Gemma Translator STL. Load it in CadQuery or OpenSCAD, add openings for the display, speaker, NFC antenna area and USB-C, and print one test fit. Record print time and filament grams.
BOM: write BOM.csv with part, supplier, quantity-10 unit price and URL for every item, packaging included. Compute unit cost and minimum price at 2.5x BOM; compare with the Y-Pan's roughly $100 parts benchmark.

Expect: display/ and nfc/ code, case/ source and STL, a test-fit photo, BOM.csv, pricing.md.

Audit before moving on: Every BOM row needs a live URL and a quantity-10 price. The display must show a fresh play number after 5 power cycles. If the case blocks NFC reads at 1-3 cm, thin the wall and reprint.

Step 7 — Validate and write the gap report

Goal: Prove the format is more than a curio or kill it honestly.

Run the falsifier from the dive: if listeners prefer the fixed studio take every time, or the BOM forces a price above what 10 fans will pay, the format is a curio.
1. Blind listening test: recruit at least 20 listeners. For each, play the studio master and three random device takes in shuffled order, unlabeled. Ask: can you tell which is the studio take (ABX), and which do you prefer. Record raw answers in listening.csv. Report preference share with a binomial confidence interval.
2. Pre-sale: offer 10 units to existing listeners at the price from pricing.md with a clear ship date. Record conversions and the price.
3. Soak: re-run 1,000 plays on the final hardware with voice and display enabled; report duplicates, loudness, underruns and resets.
4. Write gaps.md: each claim verified / unverified / false with evidence, deliverable status, risks ranked by impact. Fix what you can now; list the rest with reasons.

Expect: listening.csv and listening_report.md, presale.md, final soak_report.md, gaps.md with a verdict line: product, curio, or needs another iteration.

Audit before moving on: Verify the listening test was actually blind: the person running playback must not know which file is which, or use a script that shuffles and logs. If fewer than 20 listeners or fewer than 10 pre-sale offers were made, the verdict must read 'inconclusive', not 'product'.

4 · Gap analysis and audit

Run this after the build. It makes the agent enumerate its own claims, mark what is verified, rank the gaps and fix the top ones.

You are auditing a finished generative hardware music edition. You did not build it. Read claims.md, grammar.yaml, bench.md, voice_bench.md, BOM.csv, pricing.md, soak_report.md, listening_report.md and presale.md.
1. List every factual claim in those files (speeds, sizes, prices, uniqueness, loudness, runtime, listener preference) as a numbered table.
2. For each, mark verified, unverified or false, and cite the evidence: a log line, a measurement, a URL, a photo. A claim copied from a creator post with no local measurement is unverified.
3. Re-check: Pocket TTS speed on the shipped board; unique hashes in soak.log; true peak at or below -1 dBTP; counter survives power loss; BOM sourced at quantity 10; blind test with 20+ people; voice consent exists.
4. List what a 10-unit run still lacks: spares, shipping, returns, a firmware update path.
5. Rank all gaps by impact on the falsifier (does it change the product-or-curio verdict).
6. Fix the top three now where possible: rerun a measurement, correct a number, add a missing test.
7. Report what you could not fix, why, and who or what would close it.

Questions the agent must ask itself before it says done:

5 · What proves it right

6 · Failure modes

7 · Agent direction (unattended runs)

Start with local stem inspection and the two repositories; no hardware work until the grammar exists and the soak passes on a desktop. Cache stems_report.csv and models/ so reruns do not refetch. After step 3, spawn parallel sub-agents for case-plus-BOM and for the voice benchmark; they share no files. Stop and ask the user when stems are misaligned, when voice consent is missing, when the computed minimum price exceeds their target by more than 50%, or when a hardware measurement needs a device they have not confirmed owning. Never fabricate a bench number; write 'not measured: no device' instead. Return a top-level README.md that links claims.md, grammar.yaml, player/, bench.md, voice/, display/, case/, BOM.csv, pricing.md, soak_report.md, listening_report.md and gaps.md, with a one-line status for each and the final product-or-curio verdict.

Prompt system updated 2026-10-22 · all prompt systems · JSON

Browse more deep dives at DejaViewed — 846 entries across the full catalog.

Generated 2026-10-22 · curated by @6ab3 for DejaViewed