20 - Guide Maintenance

Purpose

This page explains how to keep the guide useful over time.

The guide should stay practical, connected, and decision-focused. It should not become a dump of every plugin opinion, every possible chain, or every unfinished idea.

Main Rule

Every addition should reduce confusion or improve decision-making.

Before adding a new page, recipe, plugin, or rule, ask:

• Will this help me make music faster?
• Will this reduce plugin decision fatigue?
• Does this connect to my actual tools?
• Does this fit my target sound?
• Is this a repeatable workflow or just a passing thought?
• Does it belong in a general guide page, a sound recipe, or the raw inventory?

If the addition does not help future decisions, leave it out or keep it as a note outside the main guide.

Page Types

Core Guide Pages

Use for broad creative process and decision rules.

Examples:

• Start Here
• Creative Method
• Songwriting and Sound Selection

These pages should answer:

• How do I think?
• What order should I make decisions in?
• How do I avoid getting stuck?

Instrument Pages

Use for general guidance by musical source.

Examples:

• Vocals
• Guitar
• Synths and Keys
• Bass
• Drums and Percussion

These pages should answer:

• What role does this instrument play?
• What sources should I use first?
• What chains make sense?
• What common problems happen?
• What related sound recipes exist?

Instrument pages should not become artist recipes. Put specific artist/style sounds in sound-recipes/.

Production Pages

Use for process, mix decisions, creative effects, repair, mastering, and technical workflow.

Examples:

• Creative Effects and Transitions
• Mix Bus and Mastering
• Repair, Cleanup, and Problem Solving

These pages should answer:

• What job am I solving?
• What order should I work in?
• What tool should I reach for first?
• What should I avoid?

Reference Pages

Use for indexes, inventories, overlap maps, and maintenance rules.

Examples:

• Sound Recipes Index
• Plugin Inventory
• Overlap and Redundancy Map
• Guide Maintenance
• Plugin Evaluation

These pages should answer:

• What exists?
• Where is it?
• What overlaps?
• How do I keep the guide consistent?

Sound Recipes

Use for specific target sounds, artist references, production worlds, or repeatable chains.

Examples:

• Dave Gahan / Depeche Mode Vocal
• Duane Eddy / Spaghetti Western Guitar
• Lana Del Rey / Cinematic Western Guitar
• One Dove / Dubby Dream-Pop Atmosphere
• One Dove / Why Don't You Take Me Dream-Pop Groove

Sound recipes should answer:

• What is the target?
• What source should I start with?
• What is the fast path?
• What is the produced path?
• What tools matter?
• What should I avoid?
• What variations are useful?

File Naming Rules

Paths below are relative to content/.

General Pages

Use numbered files and clear titles.

Examples:

core-guide/01-start-here.md
instruments/07-guitar.md
production/13-mix-bus-and-mastering.md
reference/15-plugin-inventory.md

Rules:

• Keep numbering consistent.
• Use lowercase file names.
• Use hyphens, not spaces.
• Use plain descriptive titles.
• Do not duplicate the heading if the file already has one.
• Remove placeholder text when filling a page.

Sound Recipe Files

Use lowercase, hyphenated file names based on the recipe title.

Examples:

sound-recipes/vocals/dave-gahan-depeche-mode-vocal.md
sound-recipes/guitar/duane-eddy-spaghetti-western-guitar.md
sound-recipes/guitar/lana-del-rey-cinematic-western-guitar.md
sound-recipes/synths-and-production/one-dove-dubby-dream-pop-atmosphere.md
sound-recipes/synths-and-production/one-dove-why-dont-you-take-me-dream-pop-groove.md

Rules:

• Keep recipe names clear and stable.
• Do not silently rename planned recipes.
• If a name changes, update every connected page.
• Use Dream-Pop with a hyphen in display titles when used as a compound adjective.
• Use readable artist/style names in the title.

Linking Rules

When adding or completing a sound recipe, update all connected pages.

At minimum:

1. Add the recipe file.
2. Add or update the relevant instrument/production page under Related Sound Recipes.
3. Add the recipe to reference/14-sound-recipes-index.md.
4. Remove it from Planned: if it was previously listed there.
5. Check for spelling/name consistency.

Example:

If creating:

sound-recipes/guitar/lana-del-rey-cinematic-western-guitar.md

Also update:

instruments/07-guitar.md
reference/14-sound-recipes-index.md

If a recipe crosses categories, update every relevant page.

Example:

A dubby atmosphere recipe may belong in:

instruments/08-synths-and-keys.md
instruments/10-drums-and-percussion.md
production/11-creative-effects-and-transitions.md
reference/14-sound-recipes-index.md

Planned Recipe Rules

Planned recipe names should be treated as real commitments, not disposable notes.

Before changing a planned recipe name:

• Check whether it appears in page 14.
• Check whether it appears in an instrument or production page.
• Decide whether the new name changes the recipe meaning.
• Keep both names if they represent different recipes.

Example:

These are different recipes:

• Sound Recipe - Air / Soft Vintage Keys
• Sound Recipe - Air / Soft Vintage Synth Pad

These should both be listed if both are useful.

Sound Recipe Templates

Two shapes, both in active use. Pick by how many distinct parts the target sound has — not by how important the recipe is.

Both shapes open and close the same way. Related Pages and Practical Summary appear in every recipe — check-recipes.py warns when either is missing.

Shape A — Multi-role

Decompose the record into 5–7 numbered Core Roles before any gear talk. That decomposition is the recipe's real work; the plugin choices follow from it.

# Sound Recipe - Artist / Style Name

## Target
What the sound is, in plain language, plus 4–6 "The sound should feel:" bullets.

## Useful References
The records this is drawn from. Close with "Steal the jobs: ..." — the jobs, not the gear.

## Best For
Where in a song this belongs.

## Core Roles
1. Role name — what it does in the arrangement
2. ...  (5–7 total)

---

# 1. Role Name

## Intention
What this part is for, musically, before any tool is named.

## Source + preset starting points

| Source | ⭐ | Start From | Going For |
|---|---|---|---|

## Insert chain
In order. Say why each stage is there.

## Routing
Sends by ID — `S1 Dark Plate 12%`, `S3 Dub Delay (throw)`.

## Settings anchors (taste-check)
Numbers tied to *this* target. Delay times from BPM, envelope ms, chord voicings.

## Automation

## Taste checks

---

# 2. Role Name
...repeat...

---

# Adjustment Rules

| Problem | Try |
|---|---|

# Closest Tools I Own

# Related Pages

# Practical Summary

Fast Path belongs inside Shape A too — usually as an early numbered section, before the per-role detail.

Shape B — Single-focus

No Core Roles decomposition. The sources and the chain are the recipe.

# Sound Recipe - Artist / Style Name

## Target
## Useful References
## Best For

## Best Sources
Or a `Source | ⭐ | Start From | Going For` table if there is a real choice to make.

## Fast Path
Numbered, for writing quickly.

## Produced Path
Only when the part genuinely deserves the extra time — this is a time-vs-quality
decision device, not a longer version of the same thing.

## Common Mistake
The one that ruins it.

## Adjustment Rules

| Problem | Try |
|---|---|

## Closest Tools I Own
## Related Pages
## Practical Summary

Non-negotiables (both shapes)

• Exactly two taste knobs. Everything else locks — see 05 - Locked vs Taste.
• Reference space by send ID only (S1–S5) from 17 - Default Send Rack. Band and depth ownership live in 18 - Frequency and Depth Map. Both are locked, not taste.
• Ground it in a named primary source with a live link. Reconcile original gear to owned tools with a Their gear | Job | Reach for table — steal the job, not the brand plate. If a fact cannot be sourced, say so rather than inventing it. Where the popular assumption is wrong, add a ## The Important Correction block.
• Only cite tools that are owned, and never sample the original record — re-perform the method.
• Name the mic in any recipe with a vocal chain.
• Fold, don't create. A generic technique is not a recipe. Recipes are aesthetic targets.

Optional blocks worth adding

Optional Character Layers, Useful Variations, Avoid, and a ### Evidence sourcing block all appear in a minority of recipes. Add them when they carry a decision — not to fill the shape out.

Plugin Intake Rules

When a plugin is permanently in the library and passes the overlap check, integrate it at the same tier as comparable tools — as if it had always been there. Priority depends on sound and job, not when you bought it.

Integration Tiers

Do not list a tool in recipes just because it's new. Add it only where it is the best expensive-sounding reach or a clear produced-path upgrade over what is already there.

Overlap Before Integration

Before adding a plugin to the decision path, answer:

• What job does it solve?
• Do I already own a tool for that job?
• Is it faster?
• Is it better for the target sound?
• Is it unique?
• Does it reduce decision fatigue?
• Does it fit my target sound?
• Is it core, character, utility, special effect, or redundant?

If the plugin is owned but not important, add it only to the raw inventory.

Starting Settings (Cookbook Layer)

When a tool reaches Cookbook tier in a recipe or production page, include:

1. Source / preset starting point (category, not random presets)
2. Insert chain (order)
3. Settings anchors — tied to that recipe's target sound, labeled as starting anchors (taste-check)
4. Routing (sends vs inserts)
5. Taste checks

Rules:

• Anchors must serve the expensive electronic art-pop goal — not generic manual dumps.
• Use Fast Path vs Produced Path when one tool is faster and another sounds better dialed in.
• Only one ⭐ per job per recipe row — the best expensive default. Alternates go in produced path without competing stars.

Favorite Patches (Optional, Add When Found)

When you discover a patch or setting you love on a plugin, add it under that tool's section:

### Favorite patches

- **Patch name** — job / recipe it serves — why it works

Keep the list short (a few per plugin). Favorite patches supplement starting anchors; they do not replace the taste-check workflow until validated in more than one song.

New Plugin Intake

Full framework + completed evaluations: 21 - Plugin Evaluation

When auditioning anything new, always answer:

1. What does it do? (plain English)
2. What job is it for?
3. vs your stack: Upgrade / Downgrade / Basically the same / Different job
4. Which owned plugin it sits next to
5. Cookbook tier: Cookbook / Situational / Deep Lab / Audition / Skip
6. Expert reviews — named source + one-line takeaway (SOS, MusicRadar, manufacturer measurements, credible YouTube skeptics — not random forum hype)
7. Bypass test — 10-minute A/B against current ⭐ default
8. Guide updates if kept

Copy the blank template from 21 - Plugin Evaluation for each new candidate. Publish completed evaluations on that page; do not scatter verdicts across random notes.

Quick Intake Template (copy)

## [Plugin Name]

**Company:** | **Type:** | **Price:** | **Evaluated:** YYYY-MM-DD

### What it does (plain English)


### Job


### vs your stack — [Upgrade / Downgrade / Basically the same / Different job]

| Your tool | Comparison |
|---|---|

### Cookbook tier — [Cookbook / Situational / Deep Lab / Audition / Skip]

### Expert reviews

| Source | Takeaway |
|---|---|

### Bypass test (10 min)


### Guide updates if kept


### One-sentence summary

Rating System

Workflow Role

Fuss Rating

Priority for My Sound

Git and Commit Rules

Use Git to preserve clean checkpoints as the guide evolves.

Use a lightweight Conventional Commits format so the commit history stays readable now and still works later if this guide becomes a website.

Commit after meaningful completed units, not after every tiny edit.

Good commit points:

• Filling a new page
• Creating a new sound recipe
• Updating connected recipe links
• Adding a plugin inventory section
• Cleaning naming or structure
• Updating README/navigation
• Adding website structure or styling
• Changing build/config/deploy files

Avoid committing:

• Half-written pages
• Broken links
• Temporary placeholder text
• Unreviewed recipe name changes
• Large unrelated changes in one commit

Commit Message Format

Use this format:

type(scope): short action summary

Scope is optional:

type: short action summary

Examples:

docs(readme): update guide navigation
docs(recipes): add Lana cinematic western guitar
docs(index): update sound recipe links
docs(inventory): add raw plugin inventory
chore(maintenance): add commit rules
fix(links): correct One Dove recipe path
feat(site): add recipe navigation
style(site): add responsive layout
build(site): configure markdown rendering
deploy(github): configure GitHub Pages

Subject Line Style

Use this style for the first line of the commit message:

• Use lowercase commit types.
• Use present tense / imperative style.
• Keep it short.
• Do not end with a period.
• Use proper capitalization only for names that require it.
• Keep one logical change per commit when possible.

Good:

docs(readme): update guide navigation
docs(recipes): add Air soft vintage synth pad
feat(site): add instrument page links
fix(links): correct One Dove recipe path

Avoid:

Updated README navigation.
Added some stuff.
Fixes.
recipes: Add Air Soft Vintage Synth Pad.

Reason:

The commit subject acts like a label or changelog entry, not a sentence. Lowercase type names and no trailing period keep the history consistent and easy to scan.

Commit Types

Recommended Scopes

Use scopes to show what area changed.

Scopes are optional. Use them only when they make the commit easier to understand.

Guide Content Examples

docs(vocals): fill vocal guide
docs(guitar): add Gretsch source guide
docs(recipes): add One Dove dubby dream-pop atmosphere
docs(index): add bass and drums planned recipes
docs(inventory): add UAD raw inventory categories
docs(overlap): map synth defaults
docs(maintenance): add plugin intake rules
fix(index): correct Air recipe naming
style(markdown): normalize recipe index spacing

Website Examples

feat(site): add homepage
feat(nav): add recipe category navigation
feat(site): render Markdown guide pages
style(layout): add responsive two-column layout
style(type): refine heading scale
build(site): configure static site output
config(markdown): add Markdown processing rules
deploy(github): configure GitHub Pages
ci(github): add link check workflow

Suggested Push Rhythm

Push after a group of safe commits.

Good times to push:

• After finishing a guide section
• After adding several recipes and connected links
• After updating README/reference pages
• Before making major restructuring changes
• Before starting website conversion work
• After a website feature works locally

Rule:

Commit locally for checkpoints. Push to GitHub when the current state is coherent.

Maintenance Checklist

Use this after any significant edit.

If Adding a New General Page

• Remove placeholder text.
• Do not repeat the heading.
• Keep the title and file number consistent.
• Add links only where useful.
• Avoid dumping unrelated plugin lists into the page.

If Adding a New Sound Recipe

• Create the recipe file.
• Link it from the relevant instrument/production page.
• Add it to page 14.
• Remove it from planned lists.
• Check recipe title consistency.
• Check file name consistency.
• Add related pages at the bottom of the recipe.

If Adding a New Plugin

• Add it to raw inventory if owned.
• Add it to decision tables only if it should affect workflow.
• Add it to overlap map only if it creates meaningful overlap.
• Add it to instrument/production pages only if it is a realistic reach-for tool.
• Do not make sale purchases look like core tools automatically.

If Renaming a Recipe

• Update page 14.
• Update all related instrument pages.
• Update all related production pages.
• Update the file name if needed.
• Update internal links.
• Check whether the old and new names actually describe different recipes.

Link Checking

Cross-links are the backbone of the guide, so keep them honest.

Run the link checker after editing links, renaming files, or adding recipes:

python3 scripts/check-links.py
python3 scripts/check-recipes.py

After UA Connect or Apollo authorization changes, also run locally (not CI):

python3 scripts/check-uad-all.py

Export ~/Desktop/UADSystemProfile.txt first if the DSP half reports a missing profile. See 15 - Plugin Inventory — UAD format.

It validates every relative Markdown link (and #anchor) and exits non-zero on any broken link. The same check runs automatically on push and pull requests via the link-check GitHub Action (.github/workflows/link-check.yml).

If it reports a broken link, fix the path or anchor before committing — do not commit broken links.

Recipe Checking

The link checker proves links resolve; the recipe checker proves every recipe is well-formed and fully connected.

Run it after adding or renaming a recipe:

python3 scripts/check-recipes.py

For every file under sound-recipes/ it verifies:

1. The file has a # Sound Recipe - ... H1 title.
2. The recipe is listed in reference/14-sound-recipes-index.md.
3. The recipe is linked from at least one guide page outside the index and outside sound-recipes/ (an instrument, production, core, or reference page) — i.e. the linking rules above were actually followed.

It also prints non-fatal warnings for recipes missing a Related Pages or Practical Summary section. It exits non-zero on any structural or linking error, and runs in the same GitHub Action as the link checker.

Anti-Bloat Rules

Do not add content just because it is true.

Add content only if it helps future decisions.

Avoid:

• Long theoretical explanations
• Lists of every possible plugin
• Duplicate advice across many pages
• Unstable planned names
• Artist recipes inside general instrument pages
• Tool comparisons without a decision rule
• New plugins without an overlap check
• Chains that require too many choices

Rule:

The guide should make the next session easier, not larger.