Organising a music project: naming, folders, versions and templates.

Music projects are lost through files named track_final_v2_copy, tracks called “Audio 4” and folders understood only by their creator, not through absent ideas. Six months later, the hard part is reconstructing each track and identifying the right file rather than hearing the song.

This guide builds six foundations: naming conventions, folder structure, why to avoid v1/v2/final/final2 versions, date/status versioning, project templates and complete archiving. They support each other; one failing makes the others stop helping.

Naming conventions

A naming convention is one rule applied without exceptions. The practical rule is short: function, order number and variation where needed. For example 01_kick, 02_sub, 03_saw_lead_A, 04_lead_B. Leading numbers keep track order identical in DAWs, file explorers and stems folders.

Four rules cover almost everything:

• Function before instrument. 03_bass survives a synthesiser change; 03_serum_pad does not.
• No spaces or accents in travelling files. Spaces break paths in scripts and some exporters; accents and ñ become corrupted through systems not expecting UTF-8.
• Rename immediately. One minute renaming a changed function costs far less than reading twenty generic tracks midway through mixing.
• Same rule outside the DAW. Exported files, stems and loose audio use the track pattern rather than inventing another.

Over-clever conventions cause the opposite problem: three-letter prefixes, coded colours or abbreviations only you understand. If a first-time collaborator cannot infer a track’s identity from its name, the convention failed.

Apply it to output too. Bounces and stems inherit their originating track/group name plus status and date: 03_bass_v02_2026-10-01.wav. Even detached in email or messaging folders, the file states origin, identity and creation date—information otherwise lost when leaving your computer. One hygiene rule prevents arguments: never erase old names for appearances; rename inside the project so the next version records the change.

Folder structure

Folder structure determines whether a project travels intact or breaks when moved. A minimum scheme for any DAW:

• Project/ — the project file only.
• Audio/ — samples and recordings used, ideally copied inside rather than linked to scattered disk folders.
• Bounces/ — working exports: consolidations, references and listening versions.
• Stems/ — separate-track delivery, when required.
• Docs/ — session notes, plugin list and references.
• Backups/ — local copies; other-media copies live elsewhere.

One rule avoids red channels: material travels inside the project folder when opening elsewhere, not as references. Heavier initially, much cheaper than reconstructing lost paths. Tags and organised folders apply similarly to playback libraries: organising with playlists, tags and metadata.

Two details determine resilience away from your computer:

• One project, one folder. No loose desktop audio or projects split between working disk and laptop. Material belongs inside; otherwise move it in or document its source in Docs/.
• Subfolders by use, not download. Audio/drums, Audio/bass, Audio/fx organise how you work; Audio/pack-2024 organises original copying, irrelevant after two weeks.

Move the whole folder between disks and reopen from the new location: almost no DAW rewrites paths for you, and broken links silently mute tracks.

v1/v2/final/final2 versions: why to avoid them

Avoid v1/v2/final/final2 because it works only with one person and computer. Add a collaborator, disk change or week’s distance and the chain breaks: final gets overwritten, somebody creates final2 without consulting, and approval is unknowable.

The problem is information, not aesthetics. “Final” says nothing about date, contents or subsequent changes. A final file almost never is: an automation, naming correction or correct master is still missing.

Reject bare numbering too: track_v1, track_v2 organises, but several days on one version produce v2 and v2bis, the same problem renamed. The alternative is consistency rather than complexity.

Versioning by date and status

Date/status versioning answers what final does not: when and at which stage. Two sufficient, combinable formats:

• Date + version: track_v03_2026-10-01. Orders by date and permits same-day versions without overwriting.
• Status: track_mix_v03 or fixed suffixes such as wip, mix, master, approved. Status communicates progress to recipients.

Cadence matters more than format: save at session end and before destructive consolidation, group deletion or template changes. Saving over is not versioning; it erases the past with good intentions. Many DAWs include incremental/version saving and exporters can often add dates: use these before inventing parallel folders.

The other half is 3-2-1 backups: versioning without external copies is a single failure point with good names.

Project templates

Project templates contain always-needed things rather than everything: the folder structure above, named/routed buses, a reference track with your comparison master, default tempo and time signature, track colours and loop length.

Inclusion is simple: a setting repeated three times enters; exploration does not. Twenty loaded instruments consume CPU before any sound and delay the first note.

Save it as your DAW’s startup project and open it instead of an empty one. Update naming/folder changes: templates execute your rules; unchanged templates override changed rules.

Keep two rather than twenty: a production template with buses/references and a mix/delivery template whose groups match outgoing stems. Genre templates make sense only for genuinely different structure; tempo and one instrument alone do not justify multiplying places to forget updates.

Archiving a complete project

Complete archiving means reopening a year later elsewhere without asking for anything. Procedure:

1. Save a dated, status-labelled version.
2. Collect external material inside the project; DAWs provide this, and FL Studio ZIP includes what .flp only references.
3. Verify by opening elsewhere or making original paths inaccessible.
4. Name the archive with date/status: project_archived_2026-10-01_mix.zip.
5. Store it away from the main computer and retain a readable copy.

Everyone skips step 3, the only step making an archive real: untested restoration is well-intentioned assumption, as CISA’s backup guide stresses.

Closing-session routine

Five closing minutes replace an afternoon reconstructing:

• Rename changed functions.
• Save a dated or status-labelled version.
• Note completed and outstanding work in Docs/.
• Collect new external samples.
• Start local and other-medium copies.

Tomorrow’s project then costs less than closing today’s.

Next step

With naming, folders and versions controlled, address external dependencies: scattered samples, plugins only you own and frozen tracks. This is covered in Collect All and Save, freeze, consolidation and dependencies.