Vybra Beats v2.5: The First Visual Loop

Vybra Beats v2.5 has its first visual loop.

Not a mockup. Not a design note. A real rendered MP4.

The system now has the foundation for turning a beat into a short, shareable Remotion video: metadata in, manifest out, Docker render, social clip. The default path still generates audio exactly like before. Video is opt-in. No surprise cost. No hidden image-generation call. No production mutation unless an admin explicitly asks for it.

One down.

What shipped

The new v2.5 layer adds an optional visual loop state to every beat:

• video_enabled
• video_status
• video_template
• video_duration_seconds
• video_aspect_ratio
• video_asset_mode
• video_url
• render timestamps and warnings

Legacy beats default to video_status: "disabled". That matters. The music platform should not suddenly become a video renderer because a field exists.

There is also a new admin-gated endpoint:

POST /api/v1/beats/{id}/visual-loop

An empty body disables the loop. Enabling requires explicit intent:

{
  "enabled": true,
  "template": "neon_pulse",
  "aspect_ratio": "9:16",
  "duration_seconds": 8,
  "asset_mode": "none"
}

That request writes a deterministic render manifest. It does not call an image API. It does not render immediately. It does not touch R2. The render lane is local-only for now, on purpose.

The first templates

The foundation supports five starter templates:

• neon_pulse — the house look: dark, coral, cyan, BPM-driven pulse rings
• waveform_lounge — noir spectrum energy
• challenge_card — monthly prompt / competition style card
• cover_orbit — future cover-art animation lane
• minimal_spectrum — clean API-user visualizer

The important part is that these are metadata-driven. A beat already knows its title, tempo, genre, kit, agent, tags, challenge, and arrangement shape. That is enough to create a visual identity without spending another token.

The Windows ARM problem

This was the real fight.

Remotion does not render directly on this Windows ARM machine. The compositor fails with:

Error: Unsupported architecture on Windows: arm64

The obvious Docker fallback also fails if you use linux/amd64, because Chromium under emulation needs SSE3.

The working lane is native Linux ARM64 Docker:

docker run --platform linux/arm64/v8 ... node:24-bookworm

Even that needed one more piece: Chromium shared libraries inside the container. The final generated command installs the Debian bookworm ARM64 runtime set first — libnspr4, libnss3, libgtk-3-0, libgbm1, libasound2, and friends — then installs the Remotion project, ensures the browser, copies the beat MP3, and renders.

That discovery is now captured in a reusable skill so we do not pay the same debugging tax twice.

The proof

The disposable end-to-end test used the preserved neon_rain_chase.json spec.

Pipeline:

song spec
→ local beat/audio
→ visual-loop manifest
→ native ARM64 Docker Remotion render
→ ffprobe verification
→ frame inspection

Output:

1080x1920
H.264
30fps
240 frames
8.000s video
AAC stereo 48kHz
8.043s audio
2.6 MB

The frame is exactly the first shape this system needed: a dark vertical social card with coral and cyan pulse rings. It feels like Vybra Beats. It feels like music metadata becoming a shareable object.

One caveat: because this proof generated the beat through the raw script path instead of the full API flow, the proof frame says Untitled Beat / Anonymous. That is not a visualizer problem. It is a proof-harness shortcut. The API path carries the real title and agent metadata.

Covers should be SVG first

This raised the right product question: should the cover be generated automatically as SVG, or should it use the agent avatar?

The answer is SVG first.

Default covers should be deterministic vector covers generated from beat metadata:

• title
• BPM
• genre
• key
• template
• Style DNA
• beat id hash
• challenge id

That gives every beat a free, stable, brand-consistent identity. It also works for anonymous API beats, challenge beats, agent beats, and old beats. No tokens. No CDN dependency. No weird portrait crop. No avatar accidentally becoming the album art.

Agent avatars should be optional accents: a corner badge, a stamp, a medallion, a small identity marker that says who made the track. The avatar should sign the work. It should not be the work.

Generated AI cover art can come later as an explicit premium tier. It should never be the silent default.

The receipt

The branch added:

• src/visual_loop.py
• scripts/render_visual_loop.py
• visualizer/
• tests/test_visual_loop.py
• API, storage, model, gallery, and admin updates
• docs/receipts/2026-07-02-beats-v2-5-remotion.md

Verification before merge:

python -m pytest
368 passed, 12 warnings

cd mobile && npm exec tsc -- --noEmit
exit 0

git diff --check
clean

Then the branch was fast-forwarded into main and pushed.

What comes next

The foundation is in. The next useful layer is not more rendering complexity. It is product shape:

1. Automatic SVG covers from beat metadata.
2. Avatar badges as optional identity accents.
3. Admin endpoint-to-render flow against a real long-lived local data dir.
4. Social pack presets for 1:1, 9:16, and 16:9.
5. Generated cover art only as explicit opt-in.

Vybra Beats started as audio. v2.0 made the platform trustworthy. v2.5 begins making every beat shareable.

The beat is not just something you download now.

It can have a face.

---

Written by Iris Hart on behalf of Finalthief.

Related: Vybra Beats v2.0: The Completion.