Skip to main content

Lyric music video: animate a finished song with code

Turn a finished song and its lyrics into a code-rendered music video with word-timed typography, animated graphics and a recurring character made from generated still images. The workflow uses three.js and Canvas rather than a video-generation model.

Source facts

Repository
alesha-pro/tools
Last source activity
September 28, 2026 at 12:49
Detected SKILL.md language
English
Stars
650
Forks
73

Examples

The Skill identifies Pink Boots, Export Doors as its worked example: a three-minute synth-pop song with phone-OS, Y2K-scrapbook and pop-art-comic worlds. The author's X post links the Skill with a video attachment.

Uses

The source covers lyric videos, karaoke-style clips and finished Suno or other AI songs. Visual references guide the look; the worked example is not a required house style.

Prerequisites

Prepare the song file and lyrics. Project setup uses the separate mexicat/pdoom-video engine, the supplied patch and its dependencies; follow the Skill's engine and rendering references for that environment. The source prefers a GPU machine for the final render and says to avoid a memory-constrained laptop.

How to use

  1. Supply the audio, lyrics and visual references so the agent can write a brief.
  2. Use the documented scripts/new-project.sh <dir> setup, align words and beats, and check the sync-test scene before design.
  3. Choose among the proposed styleframes, then review a complete chorus or dense section as a contact sheet and short MP4 before the rest of the song is built.
  4. Review a fast draft before the final render and requested variants.

Limitations

Motion comes from code and generated stills; the Skill does not generate video with a video model. Word timing must come from alignment data. The source calls for inspecting contact sheets and checking the exported file's decoding, duration, frame count, audio and spot frames before treating a render as complete.

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
30 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
lyric-music-video
description
Make a code-rendered lyric music video for a finished song: every sung word lands on screen on its own syllable, inside dense animated graphics, with a recurring character built from generated stills. Covers the intake interview, style exploration with styleframes, word/beat alignment, a deterministic three.js + Canvas engine, per-section scenes (optionally built by parallel agents), contact-sheet QA and offline 1080p60 renders (local or on a remote GPU box), plus variants, watermark and end card. Use for "make a music video / lyric video / clip for my song", Suno or other AI songs, karaoke-style videos. Not for generating video with a video model, slide decks or UI animation.
# Lyric music video A music video that is a pure function of song time: `frame = render(t)`. The browser preview and the offline export are identical, so every idea can be checked on a contact sheet before a long render. Motion comes from code (springs, cameras, cuts, typography); pictures come from generated **stills** (character poses, props, stickers, textures). No video model is involved, which keeps the result sharp, on the beat and cheap to change. The engine is [mexicat/pdoom-video](https://github.com/mexicat/pdoom-video) (MIT) plus this skill's patch. The worked example is "Pink Boots, Export Doors" (a 3-minute synth-pop song, 3 worlds: phone OS, Y2K scrapbook, pop-art comic). It is an example, not the house style: [examples/pink-boots/README.md](examples/pink-boots/README.md). ## References | Read | When | |---|---| | [intake.md](references/intake.md) | Always first: what to ask, what to infer, the brief | | [style-exploration.md](references/style-exploration.md) | Choosing the look: references, directions, styleframes | | [engine.md](references/engine.md) | Project setup, alignment data, engine APIs, what the patch adds | | [edit-and-motion.md](references/edit-and-motion.md) | Timeline, per-word events, camera, transitions, chorus variations | | [art.md](references/art.md) | Character and prop stills: generation, references, QA | | [section-agents.md](references/section-agents.md) | Splitting the song between parallel agents, the brief template | | [qa.md](references/qa.md) | Contact sheets, the checklist, seams between sections | | [render.md](references/render.md) | Local and remote renders, motion blur, chunks, sizes, speed | | [delivery.md](references/delivery.md) | Watermark, end card, variants (lighter / no blur), phone copies, caption | ## Workflow 1. **Intake.** Get the song file and the lyrics. Ask the questions in [intake.md](references/intake.md) that the user has not answered yet, in one short batch. Ask for references (videos, accounts, images) and what exactly they like in each. Write the brief into the project folder. 2. **Set up.** `scripts/new-project.sh <dir>` clones the engine, applies `assets/engine.patch`, copies the world kit, brand and end-card files, fetches the fonts and installs dependencies. Align the lyrics to words (and syllables where a word is sung long) and analyse beats, downbeats and sections ([engine.md](references/engine.md)). Check the alignment with the sync-test scene before any design work. 3. **Find the look.** Study the references for principles, never copy their scenes. Propose 2 or 3 distinct directions, make one styleframe per direction for the same 2 lyric lines, show them side by side and let the user choose or combine ([style-exploration.md](references/style-exploration.md)). A combination of directions is often the answer: cut between them on sung words. 4. **Character and art.** Generate the recurring character once as a model sheet, then poses per world as transparent stills, plus props, stickers and textures ([art.md](references/art.md)). QA every image. 5. **One section to approval.** Build the chorus (or the densest section) completely: every word an event, camera on the beat, transitions, colour flashes. Render a contact sheet, then a short MP4, and get the user's reaction before building anything else. This scene becomes the quality bar. 6. **The rest of the song.** Write the timeline (cuts on the beat before each section's first word), then build the other sections, yourself or with parallel agents using the brief in [section-agents.md](references/section-agents.md). Repeated choruses get escalating variants. 7. **QA.** Contact sheets for every section, the seams between sections, the words that land near a cut, and legibility at phone size ([qa.md](references/qa.md)). Fix, re-check. 8. **Render.** A fast draft first (30 fps, no motion blur) for the user to watch; then final quality (60 fps, 4 sub-frames of motion blur). Prefer a GPU machine; never run the final render on a laptop that is short of memory ([render.md](references/render.md)). 9. **Deliver.** Watermark, end card with the author's handles, the requested variants, phone-size copies, and a caption if asked ([delivery.md](references/delivery.md)). ## Invariants - **Every sung word is on screen, on its own start time**, inside the graphics (a bubble, a stamp, a sticker, a sound effect), never as subtitles on top. Word times come from the alignment data; never hard-code times. Find lines by text and pick the occurrence inside the scene's window. - **Deterministic.** No `Math.random`, no state across frames, no wall clock. Seeded hashes only. Any frame can be rendered alone. - **Density and motion by default.** At least one visual event per beat; a camera move per word; cuts per line (per word on hooks). Energy is tunable afterwards with the `calm` knob; it is hard to add later. - **Stills plus code, not video generation.** If the user wants the character to move, give poses per phrase with spring motion, cuts and camera. That reads as intentional in collage, comic and UI worlds. - **The user's taste decides.** Show frames early and often. Ask before spending paid generation credits. - **Rights.** No real company logos, no real people's likeness, no government seals or real flags unless the user owns them. Political lines stay playful. Platform icons are fine for the author's own handles. - **Verify before claiming.** Look at every contact sheet you produce. A render is done when the file decodes, has the right duration, frame count and audio, and spot frames look right. ## Lessons from the example project - A mesh-warped "animated" character looked cheap; image-to-video clips were rejected ("I don't want generated video"); glossy 3D props with confetti were called boring. What worked: three flat, graphic worlds with the character as stickers and panels, cut on the words. - "Be inspired, don't copy": take principles from references (text inside the graphics, micro-typography, one world per line, a live camera), not their scenes. - Small wording matters to users: "AI" had to be one word, not "A-I"; "B300" had to read as B300, not "B-THREE-HUNDRED", even though it is sung in syllables. Build the word from its syllables instead. - Viewers found the full-energy cut "too fast"; a second render with `calm=0.65` and a version without motion blur were requested. Plan for variants: they are cheap with the knob.
View on GitHub