hamori/CLAUDE.md

CLAUDE.md

This file gives Claude Code persistent context for the project. Read it before any non-trivial task.

Project overview

Name. hamori (Japanese ハモリ, "harmonization" in the sense of vocal harmony — adding a second voice to a melodic line). The name reflects the project's core idea: the model proposes harmonic ideas to complement a composer's existing intent, rather than writing music from scratch.

Goal. Train a small autoregressive transformer to generate harmonic periods (4–16 bar chord progressions) in the author's compositional style. Coursework deliverable for an ML class at RTU MIREA; also intended as a working creative tool.

Unit of generation. A single closed harmonic phrase (a "period"), not a full song.

Pipeline.

1. Hand-transcribe own compositions from REAPER DAW projects into .chord text files.
2. Parse .chord → factorized token sequences.
3. Pre-train on a public corpus (McGill Billboard or similar).
4. Fine-tune on the author's own corpus.
5. Sample new periods conditioned on mode / time / style / function / optional chord prefix.
6. Detokenize back to .chord + export to MIDI for use in REAPER.

Hard deadline. Less than one month, ~50 hours of work budget.

Tech stack

• Python 3.11+
• PyTorch (no Lightning unless complexity demands it — keep training loops readable)
• music21 for chord symbol parsing (music21.harmony.ChordSymbol)
• pretty_midi for MIDI generation
• pytest for unit tests
• matplotlib for plots in the report
• NumPy, pandas as standard
• Optional: Google Colab for training if local hardware is insufficient. Model is small enough that CPU is viable.

Avoid heavy abstractions. This is coursework, not a production system. Prefer simple imperative scripts over framework-style code.

Repository layout

hamori/
├── CLAUDE.md                          ← this file
├── README.md
├── requirements.txt
├── docs/
│   └── chord_format_spec.md           ← authoritative format specification
├── data/
│   ├── raw_user/                      ← hand-transcribed .chord files (own corpus)
│   ├── raw_external/                  ← public corpora (McGill Billboard etc.)
│   ├── processed/                     ← tokenized .pt files ready for training
│   └── holdout/                       ← held-out periods for evaluation
├── src/
│   ├── __init__.py
│   ├── tokenizer.py                   ← .chord ↔ token sequences
│   ├── chord_parser.py                ← chord symbol → (root, qual, ext, bass)
│   ├── midi_export.py                 ← .chord → MIDI for sanity check & user output
│   ├── dataset.py                     ← PyTorch Dataset over tokenized files
│   ├── model.py                       ← small transformer
│   ├── train.py                       ← pre-train and fine-tune entry points
│   ├── generate.py                    ← inference / sampling
│   ├── evaluate.py                    ← perplexity + distribution metrics
│   └── external_converters/
│       └── mcgill_to_chord.py         ← convert McGill Billboard to .chord
├── tests/
│   ├── test_chord_parser.py
│   ├── test_tokenizer.py
│   ├── test_midi_export.py
│   └── fixtures/
│       └── *.chord
├── notebooks/
│   ├── 01_data_exploration.ipynb
│   ├── 02_training.ipynb
│   └── 03_evaluation.ipynb
└── checkpoints/
    ├── pretrained.pt
    └── finetuned.pt

The .chord format

The authoritative specification is in docs/chord_format_spec.md. Always read it before modifying anything that touches the format or the tokenizer. Critical points summarized here for context only — if anything conflicts, the spec wins.

• One file = one harmonic period (4–16 bars).
• Header lines start with #, list title, key, time, subdivision, style, optional function.
• Body: bars separated by |, exactly subdivision positions per bar (for 4/4), positions separated by single spaces.
• A position holds: chord symbol, . (hold previous), NC (no chord), or ? (unknown).
• Chord symbols: <root><quality?><extension?>(/<bass>)?. 18 qualities, 7 extensions, slash inversions are mandatory and meaningful.
• Tokenization: each new chord becomes exactly 4 tokens (ROOT_x, QUAL_x, EXT_x, BASS_x). Hold = HOLD. Bar boundaries are not tokens — the detokenizer reconstructs them by counting positions (TIME × SUB). Plus metadata tokens at the start.
• Keys are normalized. Before tokenization, the entire period is transposed: majors → C major, minors → A minor. The model never sees absolute keys. The vocabulary contains MODE_major/MODE_minor but no KEY_x tokens.
• Vocabulary size: 84 tokens.

Model

A small autoregressive transformer:

• Layers: 2–4
• d_model: 128–256
• Heads: 4–8
• FFN dim: 4 × d_model
• Context length: 512 tokens (more than enough for any single period)
• Tied input/output embeddings
• Standard causal mask, next-token prediction with cross-entropy
• AdamW, cosine schedule, warmup ~5% of steps
• Dropout 0.1–0.2

Pre-training uses the full public corpus. Fine-tuning uses the own corpus with a smaller learning rate (e.g. 1e-5 vs 1e-4 for pre-training) and few epochs (5–15) to avoid catastrophic forgetting of harmonic regularities learned during pre-training.

Inference

• Top-p sampling (nucleus, p ≈ 0.9) with temperature ≈ 1.0 as defaults. Tunable.
• No beam search — it generally hurts on generative tasks like this.
• Generation is conditioned by feeding the BOS + metadata tokens explicitly, then optionally a chord prefix from the user.
• After generation, transpose from C/Am to the user's requested key.
• Output: both a .chord file and a MIDI file.

Evaluation

For the report:

1. Perplexity on the holdout set, comparing pre-trained baseline vs fine-tuned.
2. Distribution shift plots — histograms over chord qualities, extension presence, inversion frequency, root motion intervals — showing how fine-tuning moves the distribution toward the author's corpus.
3. Qualitative cherry-picked generations — 3 examples with the same seed/prefix, generated by baseline vs fine-tuned, rendered to MIDI.

No formal blind listening test (out of scope for the deadline).

Working language

• Code, identifiers, code comments, log messages, commit messages: English.
• User-facing output, the academic report, and the README user guide: Russian (per university requirements; the report must comply with GOST).
• Conversations with the developer (the author): Russian.

When generating commit messages or code comments, write in English. When generating the report or any user-facing text, write in Russian.

Code style & conventions

• Type hints on all public functions.
• Docstrings: one-line summary + Args/Returns. Keep them concise.
• No print() in library code — use the logging module. CLI scripts may use print.
• Constants in UPPER_SNAKE_CASE at module top.
• Vocabulary, token IDs, and label maps live in src/tokenizer.py as module-level constants.
• Random seeds: every training / generation script accepts a --seed flag and sets torch.manual_seed, numpy.random.seed, random.seed.
• Reproducibility is more important than performance. If a choice is between "fast" and "deterministic", choose deterministic.

Testing policy

• Every parser/tokenizer/MIDI module has unit tests.
• Tests use small .chord fixtures in tests/fixtures/.
• Round-trip property: tokenize(parse(file)) followed by detokenize(...) must reproduce the chord sequence (up to canonical normalization).
• Don't bother unit-testing the training loop or the model. Test the data path.

Things to never do

• Do not change the .chord format without first updating docs/chord_format_spec.md and bumping its version number. The format is the contract between the human-readable data and the model; changing one side silently breaks everything.
• Do not modify files in data/holdout/ or use them during training. Holdout is held out.
• Do not add new model architectures "to compare" unless explicitly asked. One model, done well, beats four half-done.
• Do not implement bells and whistles (web UI, real-time audio synthesis, beam search, voicing models). They are explicitly out of scope.
• Do not silently round or coerce unrecognized chord symbols. If a chord can't be parsed, raise an error with the file name, bar number, and position. Silent corruption of training data is the worst failure mode here.

Things to always do

• When asked to add a feature, first identify which module it belongs in (src/...) and whether it requires a spec change. State this before writing code.
• When the user describes a bug, write a failing test first, then fix.
• When dependencies change, update requirements.txt.
• When adding a CLI script, include --help output and a usage example in the script's docstring.
• When generating a long answer, ask whether a CLI flag or a config file is preferred for new parameters. Default to CLI flags for simplicity.

Out-of-scope (explicit non-goals for this deliverable)

• Melody generation
• Voice leading / voicing inside chords above the bass
• Rhythmic patterns inside a held chord
• Arrangement, timbre, dynamics
• Web interface / GUI
• Real-time MIDI integration with REAPER
• Modulation handling inside a single period
• J-Pop fine-tuning experiment (future work after coursework deadline)

If the user asks for any of these, remind them it's out of scope and ask whether to proceed anyway or defer.