Organizar un proyecto de música: naming, carpetas, versiones y plantillas.

Un proyecto musical no se pierde por falta de ideas: se pierde por ficheros llamados tema_final_v2_copia, pistas que se llaman «Audio 4» y carpetas que solo entiende quien las creó. Seis meses después, lo que cuesta no es escuchar el tema, sino reconstruir qué estaba pasando en cada pista y cuál era el archivo bueno.

Esta guía monta esa base en seis piezas: Naming conventions, Estructura de carpetas, Versiones v1/v2/final/final2: por qué evitarlo, Versionado por fecha/estado, Project templates y Archivar proyecto completo. Las seis se sostienen entre sí: si falla una, las demás dejan de ayudar.

Naming conventions

Una Naming conventions (convención de nombres) es una única regla aplicada sin excepciones. La que funciona en la práctica es corta: función, número de orden y variación cuando la haya. Por ejemplo 01_kick, 02_sub, 03_saw_lead_A, 04_lead_B. El número delante hace que las pistas se ordenen igual en cualquier DAW, en el explorador y en una carpeta de stems.

Cuatro reglas bastan para cubrir casi todo:

• Función antes que instrumento. 03_bass sobrevive a un cambio de sintetizador; 03_serum_pad no.
• Sin espacios ni acentos en ficheros que van a viajar. Los espacios rompen rutas en scripts y en algunos exportadores; los acentos y la ñ se corrompen al pasar por sistemas que no esperan UTF-8.
• Renombra en el momento. El minuto que cuesta renombrar cuando cambias la función de una pista es mucho menor que leer veinte pistas genéricas en mitad de una mezcla.
• La misma regla fuera del DAW. Los ficheros exportados, los stems y los audios sueltos usan el patrón de las pistas, no uno nuevo.

El error contrario es la convención demasiado ingeniosa: prefijos de tres letras, colores codificados o siglas que solo tú entiendes. Si una persona que abre el proyecto por primera vez no adivina qué es una pista leyendo su nombre, la convención ha fallado.

La convención también se aplica a lo que sale del proyecto. Los bounces y los stems heredan el nombre de la pista o del grupo del que nacen, más el estado y la fecha: 03_bass_v02_2026-10-01.wav. Así, un fichero suelto en una carpeta de correo o de mensajería sigue diciendo de dónde viene, qué es y cuándo se hizo, tres datos que se pierden en cuanto el fichero sale de tu equipo. Y una regla de higiene que ahorra discusiones: nunca borres nombres viejos por estética, renómbralos dentro del proyecto para que el cambio quede registrado en la siguiente versión.

Estructura de carpetas

La Estructura de carpetas decide si el proyecto viaja solo o se rompe al moverlo. Un esquema mínimo que funciona en cualquier DAW:

• Proyecto/ — el fichero del proyecto y nada más.
• Audio/ — los samples y grabs que usa el proyecto, idealmente copiados dentro y no apuntados a carpetas sueltas de disco.
• Bounces/ — exportaciones de trabajo: consolidados, referencias, versiones para escuchar.
• Stems/ — la entrega en pistas separadas, cuando la haya.
• Docs/ — notas de sesión, lista de plugins, referencias.
• Backups/ — copias locales; fuera de esta carpeta van las copias en otros soportes.

La regla que evita los canales en rojo es una sola: al abrir un proyecto en otro equipo, el material viaja dentro de la carpeta del proyecto, no se referencia. Es más pesado al principio y muchísimo más barato que reconstruir rutas perdidas. La misma lógica de etiquetas y carpetas ordenadas sirve para la biblioteca de reproducción: Organizar la biblioteca con playlists, etiquetas y metadata.

Dos detalles que deciden si la estructura aguanta fuera de tu equipo:

• Un proyecto, una carpeta. Nada de audios sueltos en el escritorio ni proyectos repartidos entre el disco de trabajo y el portátil. Si el material no cabe dentro, no es material del proyecto: o se mueve para dentro, o se documenta en Docs/ de dónde sale.
• Subcarpetas por uso, no por descarga. Audio/drums, Audio/bass, Audio/fx ordenan según cómo trabajas; Audio/pack-2024 ordena según de dónde copiaste algo, y eso deja de importar a la segunda semana.

Cuando muevas el proyecto a otro disco, mueve la carpeta entera y vuelve a abrirlo desde la nueva ubicación: casi ningún DAW reescribe rutas por ti, y los enlaces rotos no avisan, simplemente silencian pistas.

Versiones v1/v2/final/final2: por qué evitarlo

Versiones v1/v2/final/final2: por qué evitarlo: porque es un sistema que solo funciona mientras haya una persona trabajando y un solo ordenador. En cuanto entran un colaborador, un cambio de disco o una semana de distancia, la cadena se rompe: final se sobrescribe, alguien crea final2 sin consultar y ya no hay forma de saber cuál es la versión aprobada.

El problema no es estético, es de información. «Final» no dice cuándo se hizo, ni qué contiene, ni si hubo cambios después. Y el fichero llamado final casi nunca lo es: siempre falta una automatización, una corrección de nombre o el máster correcto.

Descarta también la numeración sin más: tema_v1, tema_v2 ordena, pero si trabajas varios días en la misma versión acabas con v2 y v2bis, que es el mismo problema con otro nombre. La alternativa no es más compleja, solo constante.

Versionado por fecha/estado

El Versionado por fecha/estado resuelve lo que la carpeta final no responde: cuándo se hizo y en qué punto estaba. Dos formatos combinables y suficientes:

• Fecha + versión: tema_v03_2026-10-01. Ordena por fecha y permite varias versiones al día sin pisarse.
• Estado: tema_mix_v03 o sufijos fijos como wip, mix, master, aprobado. El estado comunica el avance a quien recibe el fichero.

La cadencia importa más que el formato: una versión al cerrar cada sesión y otra antes de cualquier operación destructiva (consolidar, borrar grupos, cambiar la plantilla). Guardar encima no es versionar; es borrar el pasado con buena intención. Muchos DAW ya incluyen guardado incremental o de versión, y los exportadores suelen poder añadir la fecha al nombre: úsalos antes de inventar una carpeta paralela.

La otra mitad del sistema está en Copias de seguridad con la regla 3-2-1, porque versionar sin copias fuera del equipo es un único punto de fallo con buenos nombres.

Project templates

Unas Project templates no son un proyecto lleno de cosas: son un proyecto con lo que siempre necesitas. Incluye la estructura de carpetas de arriba, los buses ya nombrados y routados, una pista de referencia con el máster que usas para comparar, el tempo y el compás por defecto, los colores de pistas y la longitud de loop.

El criterio de inclusión es simple: si has repetido el ajuste tres veces, entra en la plantilla; si es exploración, no. Una plantilla con veinte instrumentos cargados consume CPU antes de que suenes y retrasa la primera nota.

Guarda la plantilla como proyecto de inicio de tu DAW y ábrela en lugar del proyecto vacío. Actualízala cuando cambie tu convención de nombres o de carpetas: la plantilla es la forma executable de tus reglas, y si las reglas cambian y la plantilla no, manda la plantilla.

Conviene tener dos, no veinte: una plantilla de producción, con buses y pistas de referencia, y una plantilla de mezcla o entrega, con los grupos ya ordenados como van a salir en stems. Plantillas por género tienen sentido solo cuando de verdad cambia la estructura; si la diferencia real es el tempo y un instrumento, duplicar la plantilla solo multiplica sitios donde olvidar una actualización.

Archivar proyecto completo

Archivar proyecto completo significa poder reabrirlo dentro de un año en otro equipo, sin pedirle nada a nadie. El procedimiento:

1. Guarda versión con fecha y estado.
2. Recopila todo el material externo en la carpeta del proyecto (los DAW ofrecen esa opción; en FL Studio, el paquete zip incluye lo que el .flp solo referencia).
3. Comprueba el archivado abriendo el paquete en otro equipo o con las rutas originales inaccesibles.
4. Nombra el archivo con fecha y estado: proyecto_archivado_2026-10-01_mix.zip.
5. Colócalo en un soporte fuera del equipo principal y deja una copia legible.

El paso 3 es el que se salta todo el mundo y el único que convierte un archivado en real: una restauración sin probar es una suposición con buena intención, tal y como insiste la guía de copias de la CISA.

La rutina de cierre de sesión

Cinco minutos al cerrar sustituyen una tarde de reconstrucción después:

• Renombra lo que cambió de función.
• Guarda versión con fecha o estado.
• Anota en Docs/ lo hecho y lo pendiente.
• Recopila el material externo si has añadido samples nuevos.
• Lanza la copia local y la copia en otro soporte.

Con esa rutina, el proyecto de mañana cuesta menos que cerrarlo hoy.

Siguiente paso

Con los nombres, las carpetas y las versiones bajo control, el siguiente escollo es lo que el proyecto arrastra de fuera: samples sueltos, plugins que solo tienes tú y pistas congeladas. Ese terreno se cubre en Collect all and save, freeze, consolidación y dependencias.