AI-generated music, published with no human in the loop: the Bachata Vibes Music pipeline

1. Introduction

The starting question wasn't "can AI generate passable music" — the answer to that is well established by now. It was: can a system handle the entire cycle by itself — production, visual editing, publishing, failure handling — reliably enough to run for months without constant supervision? Bachata Vibes Music is the practical answer: a music channel (bachata, salsa, merengue, cha cha cha) active since March 2026, with over 870 videos published at the time of writing, run by a single Raspberry Pi 5 that orchestrates every stage with no human DJ.

The project constraint is the exact opposite of Guerda Music, another project by the same author: there, the voice has to stay human and real; here, AI generates it entirely. The two projects share infrastructure (same Raspberry Pi, same rendering machine) but answer to opposite editorial constraints — a useful case for isolating what actually changes when you remove the last human element from the production chain.

2. System architecture

The system is spread across three machines with intentionally unequal roles, connected by an asynchronous queue on Google Drive instead of a direct always-on connection:

The most counter-intuitive choice was the last one: using Google Drive as a bridge between the Pi and the PC instead of a direct connection (SSH/API). A desktop PC isn't built to stay on 24/7 as reliably as a low-power Raspberry Pi. Rather than make the whole system dependent on the PC's uptime, the Pi writes a render request to a Drive folder and moves on; a worker on the PC picks it up whenever the machine is on, and writes the result to another folder the Pi collects on its next pass. The decoupling doesn't eliminate the problem — if the PC stays off for days the queue grows — but it turns a potential total pipeline stall into a local, recoverable delay.

3. The production pipeline, step by step

Every hour, the orchestrator on the Pi evaluates whether to produce new material or consume what's already queued, based on the system's real state (remaining YouTube quota, rendering queue, content already published today). When it produces:

1. Genre selection — a scoring module reads the channel's real retention curves (how long viewers stay on bachata sensual vs. merengue vs. cha cha cha over the last week) and picks the day's category accordingly, not on a fixed rotation
2. Lyrics — Claude generates lyrics consistent with a theme, with a static pool as fallback if the API doesn't respond
3. Audio — the request goes to Suno via REST API (with a browser-automation path as fallback when the API is unavailable); the title passed at this stage is deliberately generic (category + timestamp), not the final title — a minor technical detail that once caused a real bug, later fixed (see section 4)
4. Cover art — a background generated or pulled from an existing pool, then branded with text, logo and a color palette specific to the subgenre
5. Video — a render request sent to the Drive bridge; the PC processes it with FFmpeg/NVENC when available
6. Publishing — YouTube upload via the Data API with quota management, automatic generation of publishing folders for Facebook/Instagram/TikTok with timing computed from per-platform optimal slots

4. Handling failures with no one on call

The most interesting part of a system that has to run for months without supervision isn't generation itself — it's what happens when something breaks, and it's statistically certain that sooner or later something will break: an external provider changes behavior, an API introduces an undocumented rate limit, an overly optimistic timeout fails an otherwise harmless step. A few patterns turned out to be necessary in production, not planned in advance:

Degrade, don't block. Every external component (PC rendering, audio generation, upload) has a fallback path or a timeout that lets the rest of the pipeline keep going. If rendering is unavailable, the request stays queued instead of blocking the next hourly cycle.

Sentinel files instead of code flags. To temporarily pause a single component (for example TikTok publishing during an algorithmic shadowban period) it's enough for a file to exist on the filesystem, checked at every run — no code change, no deploy, reversible by deleting the file.

Always verify real state, never the declared response. The most instructive case: an image-hosting provider always responded with Content-Length: 0 to a HEAD verification request, even when a real GET request on the same URL served the full file — the pipeline treated every publish as blocked for a full day before the verification code was fixed to use a streaming GET instead of trusting the header. The general lesson: when an external system is outside your control, verifying observed behavior is more reliable than trusting the API's declared contract.

Concurrency between runs. A cron running every 30 minutes can overlap with a previous run still in progress (for example after a network slowdown) — without an explicit lock with a timeout, this produces duplicate publishes. A lock file with an expiry (automatically released if a process dies without cleaning up) eliminated the whole class of bug.

An autonomous system isn't one that never breaks — it's one where a local failure stays local, self-reports, and doesn't need a human awake at 3am to be contained.

5. Operational results

Some concrete numbers collected over the first six months of continuous activity (March–September 2026):

• 870+ videos published on YouTube, with generation, rendering and publishing fully automated in the ordinary cycle
• Four music genres produced autonomously (bachata sensual, salsa, merengue, cha cha cha), with the day's genre driven by real retention data, not a fixed calendar
• Multi-platform publishing (YouTube, Facebook, Instagram, TikTok) from a single ready-content queue, with per-platform timing computed from historically best-performing slots
• Marginal cost per track in the range of a few cents of a dollar for the text component (Claude Haiku), against a fixed Suno subscription cost for audio generation independent of volume

6. Limitations, and what the pipeline doesn't solve on its own

Intellectual honesty before marketing: not everything can be safely automated, and not everything that can be automated should be automated without oversight. A few concrete examples:

• Detecting algorithmic shadowbans (TikTok, in particular) remains a continuous statistical monitoring problem — the system detects the pattern (a views crash on new uploads regardless of content quality) but the decision on how to react (slowing the cadence, changing hashtag strategy) is still an editorial call, not delegated to automation
• Platforms with explicit anti-bot policies (LinkedIn, for connected projects) impose a limit that isn't technical but a matter of account risk — there, automation deliberately stops one step before publishing
• Aggregate editorial quality — a system producing daily tends to converge on safe patterns (same themes, same text structures) unless periodically pushed toward new variations: creative diversity requires a deliberate intervention, it doesn't emerge on its own from automated repetition

Conclusion

The result isn't "AI replaces a record label" in any absolute sense — it's that a system designed for controlled degradation, more than for the absence of failures, can sustain months of continuous production and publishing with a much lower human-supervision load than intuition would suggest. The technically interesting part wasn't teaching a model to generate a plausible bachata song — it was building the infrastructure around it that lets that generation happen reliably, day after day, with no human pressing play.