Un prompt peut-il remplacer Soundtrap ?

Mets en place un flux de production musicale local autour d’une station de travail audio numérique open source, et résous la moitié collaboration avec du contrôle de version plutôt qu’en prétendant la résoudre en direct.

Installe Ardour pour un travail centré sur l’audio ou LMMS pour une production centrée sur les patterns. Ne construis pas de station de travail.

Le projet qui vaut la peine d’être écrit, c’est la couche de partage de session. Mets chaque projet dans un dépôt git avec git-lfs pour l’audio, et écris un petit outil qui : prépare une session pour le partage en consolidant chaque sample référencé dans le dossier du projet (l’échec classique est une session qui s’ouvre avec des fichiers manquants sur la machine de quelqu’un d’autre) ; enregistre la liste des plugins avec leurs versions dans un manifeste ; et refuse de commiter si un plugin n’est pas dans une liste partagée et convenue.

Ajoute un hook de rendu-au-commit qui produit un mixdown stéréo dans un dossier `exports/` nommé d’après le commit. Ça donne à chaque collaborateur une version écoutable de chaque révision sans ouvrir le projet, ce qui est en grande partie à quoi sert vraiment la collaboration en temps réel.

Pour les boucles, construis une bibliothèque de samples locale et taguée sur du matériel que tu as sous licence ou enregistré : un scanner de dossier qui lit le BPM et la tonalité depuis les noms de fichiers ou les détecte, les écrit dans un index SQLite, et propose une recherche par plage de tempo et tonalité. Stocke la licence de chaque pack dans l’index, pour que « puis-je sortir ça ? » ait une réponse.

N’implémente pas d’édition collaborative en direct. L’édition concurrente sans conflit d’une timeline avec de l’audio est un problème de niveau recherche, et une version à moitié fonctionnelle perd des prises.