Lyria Studio
Un outil musical qui génère un morceau à partir d'un prompt dans un chat avec le modèle Lyria RealTime de Google, puis l'ouvre dans un studio pour le découper en sections et régénérer n'importe laquelle. Je l'ai construit pendant mon stage chez DevFortress, d'abord comme un seul prototype Streamlit, puis en trois parties : un chat Next.js, un backend FastAPI et un studio Streamlit.
Architecture
Le chat est une page Next.js qui envoie le prompt, la durée, le BPM et la densité à un point d'accès FastAPI. Le backend ouvre un WebSocket vers Lyria RealTime via l'API Gemini, écrit l'audio reçu en flux dans un fichier WAV et renvoie le fichier au chat, qui le fait jouer. Un lien Open in Studio transmet le nom du fichier et le prompt d'origine au studio Streamlit, qui découpe le morceau en sections égales et régénère celle que je choisis avec son propre prompt, son BPM et sa densité. Pydub raccorde chaque nouvelle section dans une copie de travail, et l'export enregistre le résultat dans un nouveau fichier WAV à télécharger.
Décisions clés
Un chat pour les idées, un studio pour l'édition
Le prototype était une seule application Streamlit qui passait d'une vue simple à un éditeur. Dans la V2, je l'ai séparée : un chat Next.js demande les morceaux à un backend FastAPI, et le studio Streamlit garde l'édition en Python, à côté du code audio. J'ai ainsi pu mettre le chat en ligne seul sur Vercel, pendant que le studio roule en local.
Chaque section a son propre prompt
Le studio découpe le morceau en sections égales, de 1 à 10. Une section se régénère avec son propre prompt d'in-painting, son BPM et sa densité, donc le pont peut devenir plus dense ou plus lent pendant que le reste du morceau ne bouge pas. Le prompt part de l'original, donc un petit changement donne une petite retouche.
Les retouches ne touchent jamais l'original
Une section régénérée est d'abord une candidate que je peux écouter à côté du morceau. Seul Commit Change l'insère, et seulement dans une copie de travail. L'export écrit un nouveau WAV, donc l'original généré reste toujours là pour y revenir.
Le point difficile
Faire d'un modèle de jam en direct un fichier qu'on peut éditer
Lyria RealTime est fait pour jouer en direct, comme un jam : j'envoie un prompt et PLAY par WebSocket, et l'audio arrive sans fin, parce que rien dans la requête ne fixe une durée. Pour obtenir un morceau d'une durée exacte, je compte les octets : 24 000 échantillons par seconde, deux canaux, 2 octets chacun, donc 96 000 octets par seconde. Les morceaux d'audio vont dans un WAV à mesure qu'ils arrivent, et STOP part dès que le compte est atteint. Régénérer une section au milieu a ajouté les jonctions : un nouveau clip commence et finit à froid, donc je demande à Lyria la section plus la moitié du fondu et je l'intègre aux deux bouts avec un fondu enchaîné de 1 à 5 secondes.
Sécurité et performance
- La clé d'API Google vit seulement dans une variable d'environnement du backend. Le navigateur parle à mon point d'accès FastAPI et ne voit jamais la clé ni la connexion à Lyria.
- L'API n'a pas de comptes et n'accepte qu'un prompt et trois réglages numériques. Le CORS est ouvert à toutes les origines pour l'instant, et le README précise qu'il doit être limité au domaine du chat en production.