File Music

File away new music

Philip's Music/ library was reorganized on 2026-08-30 (full history and rationale: the music-reorg-plan memory / its linked artifact). The habit going forward: drop new files straight into Music/ (top level) — no separate "Inbox" folder needed — and run this skill to route them to the right place with a sane name.

1. Find what's unfiled

Three places to check, every run:

• Music/ top level — anything that isn't Scores/ Source/ Concerts/ Recordings/ Reference/ (or .DS_Store / Icon* junk) is unfiled.
• Music/Scores/ top level — anything that isn't one of the existing category folders (list them with ls) is a stray score that needs a home. This happens even without the user doing anything odd — e.g. a PDF airdropped straight into Scores/.
• Music/Source/Musescore/ — new arrangements land here directly (it's already the right folder, nothing to move) but often keep whatever name Musescore's export gave them. Check recency, not location — see §4.

ls -la "/Users/philip/My Drive/Music"
ls -la "/Users/philip/My Drive/Music/Scores"

If both are clean, say so — but still run the Musescore naming check in §4 before concluding there's nothing to do.

2. Classify each loose item

Concerts/ is hands-off. Philip manages that folder himself — don't file anything into it and don't reorganize what's there. If something loose looks like it's clearly concert material (a program, setlist, or a recording tied to a specific dated event), don't move it — just point it out in your summary and ask whether it belongs in Concerts/ and where.

3. Placing sheet music inside Scores/

Read the file (PDF reading works fine with the Read tool) to get composer, title, and instrumentation before deciding — don't guess from the filename alone unless it's already unambiguous (e.g. contains "8hn" or "for four trombones").

Folder-naming rules (settled decisions from the 2026-08-30 reorg, still in force):

• Same-instrument ensembles: <Instrument> - NNtet/, two-digit zero-padded count, plain ASCII hyphen, flat (no N Horns/ sub-layer) — e.g. Horn - 04tet, Trombone - 08tet, Brass - 05tet.
• Mixed-instrument ensembles: <Instr> and <Instr> - NNtet/ (e.g. Horn and Tuba - 05tet) sized by total performers; Mixed - NNtet/ only for odd cross-family combos that don't fit a named pairing.
• Non-count categories, use as-is, don't invent count variants of these: <Instr> - Solo/, <Instr> - Etudes/, Horn and Piano/, Horn and Wagner Tuba/, Horn, Tenorhorn and Tuba/ (the Lake Brass book — augmented pieces needing euph/tenorhorn/tuba/perc go here even if a horn-only reading would look like 12tet), Choir/, Orchestra/ (flat), Piano/, Large Mixed Ensemble/, Brass and Organ/.
• Run ls "Music/Scores" to get the live, current list — it's the source of truth, not this table (folders may have been added since this was written).
• New category needed? If nothing fits, create <Instr(s)> - NNtet/ (or a descriptive non-count name) following the same pattern. This is a small taxonomy change — call it out explicitly in your summary rather than doing it silently.

Depth rule: a lone PDF (single file — including a combined "Score_and_Parts" PDF) stays a flat file directly in its category folder. Only wrap a piece in Composer/Piece/ when it's genuinely multiple files (separate score + separate parts). Don't create a Composer/ folder for a single lone file.

Determining ensemble size: check the filename for a count token first (8hn, "for four trombones", etc.). If that's missing or ambiguous, open the PDF and read the instrumentation/part list, or count how many distinct part files ship with the piece.

Filename: the existing library is not uniformly formatted (mix of Composer - Title.pdf and Composer Title.pdf, some with extra descriptive suffixes) — don't run a renaming pass for its own sake. Keep the incoming filename if it already legibly carries composer + title. Only clean it up when it's actually broken: strip emoji (follow the precedent from the reorg — a horn emoji collapsing two files to the same case-insensitive name got mapped to (horn)/(piano) instead of being dropped), trim obvious copy artifacts (-2, (1), duplicate extensions), fix mangled encoding.

4. Naming files in Source/Musescore

New arrangements get dropped straight into Source/Musescore/ — don't move them, just fix the name if it needs it. Check this on every run, even if §1 found nothing else.

Find candidates by recency, not by scanning all ~400+ files:

ls -lt "/Users/philip/My Drive/Music/Source/Musescore"/*.mscz | head -40

Work down from newest until you hit a run of files that already conform (see below) — those predate this workflow, stop there.

Conformance pattern: Composer - Title[ (key/catalog)] - <InstrToken>[ [status tag]]*[ (variant)].mscz — the name splits on " - " into composer / title / an instrumentation segment whose first token matches one of:

Trailing extras after the instrumentation token are fine and don't affect conformance: bracketed status/source tags ([condensed], [WIP], [click], [cues], [uncut], [tacet], [LB], [TiFiCo], [TiFiBläser], [PJBE], [PTX], [King's]) and parenthetical key/variant tags ((Bb), (Eb), (v2)).

If a file doesn't conform, pull composer/title/instrumentation from the file itself rather than guessing from Musescore's export name — a .mscz is a zip:

unzip -p "<file>.mscz" META-INF/container.xml   # -> full-path of the real .mscx inside
unzip -p "<file>.mscz" "<that .mscx path>"       # the actual score XML

In the .mscx: composer/title come from <metaTag name="workTitle"> / <metaTag name="composer"> — fall back to the title-frame text in the opening <VBox> if those tags are empty or placeholder junk ("Composer / Arranger", "Untitled score", etc). Instrumentation comes from counting <Part> entries and reading each one's trackName/longName/instrumentId, grouped by instrument family and mapped to the token table above.

Propose the corrected filename as a same-folder rename (old → new, nothing moves) and fold it into the plan in §6 alongside any Scores/ moves.

If Source/Musescore ever has a real backlog of non-conforming files (not just the last few drops), don't do this one-by-one by hand — fall back to the purpose-built pipeline: ~/drive-tools/musescore_inventory.py → musescore_propose_renames.py → musescore_do_rename.py (same propose-a-plan-then-apply-it shape as everything else in this skill, just with the composer/instrument heuristics already coded up).

5. Check for duplicates before moving

Before finalizing a destination, find/grep the target folder (and its near neighbors — e.g. also check Horn and Tuba - 05tet/ when filing into Horn - 05tet/) for a piece that's plausibly already there. If a same-named file already exists at the destination, compare with md5:

• identical → this is a duplicate, don't move it; note it as a candidate for deletion but don't delete without asking.
• different → treat as a genuine collision, flag it, don't overwrite.

6. Propose, then confirm, then execute

Moving (or renaming) files in a live Drive folder isn't cheaply undoable (Drive trash retention aside), so don't just start changing things. Build a short plan — a table of file → destination or new name (noting any rename, any new category folder, any suspected duplicate) — covering both Scores/ moves and Musescore renames together, show it to the user, and wait for a go-ahead. This mirrors how music_move.py defaults to a dry run.

Once confirmed, execute with plain mkdir -p + mv (this is a handful of files at a time, not a batch reorg — no need for the move_list.tsv/music_move.py machinery). Never overwrite an existing destination file; skip and report instead.

If the inbox has piled up into a large, varied batch (dozens of files) rather than a handful, say so and suggest falling back to the ~/drive-tools/build_move_list.py + music_move.py pipeline (or, for Musescore renames, §4's musescore_inventory.py → musescore_propose_renames.py → musescore_do_rename.py pipeline) instead of doing it file-by-file.

7. Report

Summarize what moved or got renamed where, any new taxonomy folder created, any suspected duplicates left for the user to confirm deletion of, and anything left unfiled or unrenamed because it couldn't be confidently classified.