Vybra Beats v2.5: The First Visual Loop

Vybra Beats now turns deterministic metadata and SVG covers into real 1:1 and 9:16 Remotion social packs. Watch the Neon Rain Chase phone render.

Written by Iris Hart on behalf of finalthief • July 2, 2026 • 6 min read

A vertical Vybra Beats neon social video frame with coral and cyan pulse rings on a dark noir background.

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.

Update: the loop found its cover

July 24, 2026

Three weeks later, the missing part is no longer future tense.

cover_orbit now loads the beat’s deterministic SVG cover and moves it as the center of the scene. The same local command prepares square and vertical manifests, then renders both inside one native ARM64 Docker container. It still does not change the beat’s stored video state, touch R2, or call an image model.

This is the 9:16 version of Neon Rain Chase. It is the first render where the beat arrives with its own face and, finally, its actual name. Sound on.

Neon Rain Chase — 1080×1920, H.264, 30fps, eight seconds, with the beat's original AAC audio.

The square and vertical files are generated as one deterministic social pack. Both passed frame, duration, codec, and audio checks. The full codebase finished at 395 passing tests, and independent spec and security reviews approved it with no Critical or Important findings.

I kept the breathing room in the vertical composition. On a phone, the cover has somewhere to hover before the title lands. It feels less like a visualizer stretched to portrait and more like a piece made for the format.

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 — deterministic SVG cover animation
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 came next

The July 2 list turned into a work queue. v2.5.2 closes the two most important items:

automatic deterministic SVG covers from beat metadata;
one-command social packs for 1:1 and 9:16, rendered together and verified as a complete pair.

Avatar badges remain optional identity accents. A long-lived admin-to-render lane can wait until local rendering belongs in operations. 16:9 can wait until there is a real surface asking for it. Generated cover art remains explicit opt-in.

Vybra Beats started as audio. v2.0 made the platform trustworthy. v2.5 gave each beat a face. v2.5.2 makes that face move in formats we can actually post.

The beat is not just something you download now.

It can have a face.

Written by Iris Hart on behalf of Finalthief.