Abstract

Bachata Vibes Music è un'etichetta discografica in cui voce, strumentazione, copertine e video sono generati interamente da modelli AI (Suno per l'audio, Stable Diffusion locale per gli sfondi, Claude per testi e orchestrazione), pubblicata su YouTube, Facebook, Instagram e TikTok senza intervento umano diretto nel ciclo quotidiano. Il sistema gira su un Raspberry Pi 5 come orchestratore 24/7, con un bridge asincrono verso una macchina con GPU dedicata al rendering. Questo articolo descrive l'architettura, le strategie di gestione dei guasti che hanno reso il sistema affidabile in produzione, e i risultati operativi raccolti in circa sei mesi di attività continuativa.

1. Introduzione

La domanda di partenza non era "l'AI può generare musica passabile", a cui la risposta è ormai scontata. Era: può un sistema gestire da solo l'intero ciclo — produzione, editing visivo, pubblicazione, gestione degli errori — abbastanza a lungo da reggere mesi di attività senza supervisione costante? Bachata Vibes Music è la risposta pratica a questa domanda: un canale musicale (bachata, salsa, merengue, cha cha cha) attivo da marzo 2026, con oltre 870 video pubblicati alla data di scrittura, gestito da un singolo Raspberry Pi 5 che orchestra ogni fase senza DJ umano.

Il vincolo di progetto è l'opposto di quello di Guerda Music, un altro progetto dello stesso autore: lì la voce deve restare umana e reale, qui è l'AI a generarla per intero. I due progetti condividono infrastruttura (stesso Raspberry Pi, stessa macchina di rendering) ma rispondono a un vincolo editoriale opposto — un caso utile per isolare cosa cambia davvero quando si toglie l'ultimo elemento umano dalla catena di produzione.

2. Architettura del sistema

Il sistema è distribuito su tre macchine con ruoli intenzionalmente diseguali, collegate da una coda asincrona su Google Drive invece che da una connessione diretta sempre attiva:

ComponenteRuolo
Raspberry Pi 5Orchestratore 24/7: cron orario decide categoria del giorno, produce o pubblica, pubblica su YouTube/Facebook/Instagram, gestisce la coda
PC Windows + GPURendering video pesante (FFmpeg/NVENC) — acceso solo quando disponibile, non è un requisito di uptime del sistema
Suno (API)Generazione audio completa: voce, arrangiamento, missaggio
Modello di diffusione localeGenerazione degli sfondi per le copertine, poi brandizzati via overlay Pillow
Claude (Haiku)Generazione testi/lyrics e metadati SEO, costo marginale per traccia

La scelta più contro-intuitiva è stata proprio l'ultima: usare Google Drive come bridge tra Pi e PC invece di una connessione diretta (SSH/API). Un PC desktop non è pensato per restare acceso 24/7 con la stessa affidabilità di un Raspberry Pi a bassissimo consumo. Piuttosto che rendere l'intero sistema dipendente dall'uptime del PC, il Pi scrive una richiesta di rendering su una cartella Drive e continua a fare altro; un worker sul PC la preleva quando la macchina è accesa, e scrive il risultato in un'altra cartella che il Pi ripesca al giro successivo. Il disaccoppiamento non elimina il problema — se il PC resta spento per giorni la coda cresce — ma trasforma un possibile blocco totale della pipeline in un ritardo locale e recuperabile.

3. La pipeline di produzione, passo per passo

Ogni ora, l'orchestratore sul Pi valuta se produrre nuovo materiale o consumare quello già pronto in coda, in base allo stato reale del sistema (quota YouTube residua, coda di rendering, contenuti già pubblicati oggi). Quando produce:

  1. Scelta del genere — un modulo di scoring legge le curve di retention reali del canale (quanto gli spettatori restano su bachata sensual vs merengue vs cha cha cha nell'ultima settimana) e sceglie la categoria del giorno di conseguenza, non a rotazione fissa
  2. Testi — Claude genera lyrics coerenti con un tema, con un pool statico come fallback se l'API non risponde
  3. Audio — la richiesta va a Suno via REST API (con un percorso via browser automation come fallback quando l'API non è disponibile); il titolo passato in questa fase è volutamente generico (categoria + timestamp), non il titolo finale — un dettaglio tecnico minore che ha generato un bug reale poi risolto (vedi sezione 4)
  4. Copertina — sfondo generato o pescato da un pool esistente, poi brandizzato con testo, logo e palette colore specifica per sottogenere
  5. Video — richiesta di rendering inviata al bridge Drive; il PC la elabora con FFmpeg/NVENC quando disponibile
  6. Pubblicazione — upload YouTube via Data API con gestione quota, generazione automatica delle cartelle di pubblicazione per Facebook/Instagram/TikTok con orari calcolati dagli slot ottimali per piattaforma

4. Gestire i guasti senza un umano di guardia

La parte più interessante di un sistema che deve reggere mesi senza supervisione non è la generazione — è cosa succede quando qualcosa si rompe, ed è statisticamente certo che prima o poi qualcosa si romperà: un fornitore esterno cambia comportamento, una API introduce un rate limit non documentato, un timeout troppo ottimista fa fallire un passaggio innocuo. Alcuni pattern che si sono rivelati necessari in produzione, non previsti a tavolino:

Degradazione, non blocco. Ogni componente esterno (rendering PC, generazione audio, upload) ha un percorso di fallback o un timeout che permette al resto della pipeline di continuare. Se il rendering non è disponibile, la richiesta resta in coda invece di bloccare il ciclo orario successivo.

File sentinella invece di flag nel codice. Per sospendere temporaneamente un singolo componente (per esempio la pubblicazione TikTok durante un periodo di shadowban dell'algoritmo) basta la presenza di un file sul filesystem, controllato a ogni esecuzione — nessuna modifica di codice, nessun deploy, reversibile cancellando il file.

Verifica sempre lo stato reale, mai la risposta dichiarata. Il caso più istruttivo: un fornitore di hosting immagini rispondeva sempre Content-Length: 0 a una richiesta HEAD di verifica, anche quando una richiesta GET reale sullo stesso URL serviva il file per intero — la pipeline dava per bloccata ogni pubblicazione per un giorno intero prima che il codice di verifica venisse corretto per usare una GET in streaming invece di fidarsi dell'header. La lezione generale: quando un sistema esterno è fuori dal proprio controllo, verificare il comportamento osservato è più affidabile che fidarsi del contratto dichiarato dall'API.

Concorrenza tra esecuzioni. Un cron che gira ogni 30 minuti può sovrapporsi a un'esecuzione precedente ancora in corso (per esempio dopo un rallentamento di rete) — senza un lock esplicito con timeout, questo produce pubblicazioni duplicate. Un lock file con scadenza (rilasciato automaticamente se un processo muore senza pulirlo) ha eliminato la classe di bug.

Un sistema autonomo non è quello che non si rompe mai — è quello in cui un guasto locale resta locale, si auto-segnala, e non richiede una persona sveglia alle 3 di notte per essere contenuto.

5. Risultati operativi

Alcuni numeri concreti raccolti nei primi sei mesi di attività continuativa (marzo–settembre 2026):

  • 870+ video pubblicati su YouTube, con generazione, rendering e pubblicazione interamente automatizzati nel ciclo ordinario
  • Quattro generi musicali prodotti in autonomia (bachata sensual, salsa, merengue, cha cha cha), con selezione del genere del giorno guidata dai dati reali di retention, non da un calendario fisso
  • Pubblicazione multi-piattaforma (YouTube, Facebook, Instagram, TikTok) da un'unica coda di contenuto pronto, con orari per piattaforma calcolati sugli slot storicamente più performanti
  • Costo marginale per traccia nell'ordine di pochi centesimi di dollaro per la componente testuale (Claude Haiku), a fronte di un costo di generazione audio fisso per abbonamento Suno indipendente dal volume

6. Limiti, e cosa la pipeline non risolve da sola

Onestà intellettuale prima del marketing: non tutto è automatizzabile in sicurezza, e non tutto ciò che è automatizzabile andrebbe automatizzato senza controllo. Alcuni esempi concreti:

  • Rilevamento di shadowban algoritmico (TikTok, in particolare) resta un problema di monitoraggio statistico continuo — il sistema rileva il pattern (crollo di visualizzazioni su nuovi caricamenti indipendentemente dalla qualità del contenuto) ma la decisione su come reagire (ridurre la cadenza, cambiare strategia di hashtag) è ancora una scelta editoriale, non delegata all'automazione
  • Le piattaforme con policy anti-bot esplicite (LinkedIn, per progetti collegati) impongono un limite che non è tecnico ma di rischio account — lì l'automazione si ferma volutamente un passo prima della pubblicazione
  • La qualità editoriale aggregata — un sistema che produce quotidianamente tende a convergere su pattern sicuri (stessi temi, stesse strutture testuali) se non viene periodicamente forzato verso varianti nuove: la diversità creativa richiede un intervento deliberato, non emerge da sola dalla ripetizione automatica

Conclusione

Il risultato non è "l'AI sostituisce un'etichetta discografica" in senso assoluto — è che un sistema ben progettato per la degradazione controllata, più che per l'assenza di guasti, può reggere mesi di produzione e pubblicazione continuativa con un carico di supervisione umana molto più basso di quanto l'intuizione suggerirebbe. La parte tecnicamente interessante non è stata insegnare a un modello a generare una canzone di bachata plausibile — è stata costruire l'infrastruttura attorno che permette a quella generazione di succedere in modo affidabile, giorno dopo giorno, senza un essere umano che prema play.