One Musical Truth

"One model, many readers, zero copies. The day a view keeps its own copy is the day the app starts to lie."

What the Model Actually Is

When Bonfire loads a song, it builds exactly one object: the musical truth of that song. A key. A scale or mode. A chord progression. A set of notes laid over a time grid. Sections, tempo, a beat grid. That object is the single source of truth — the model — and everything else in the app is a reader of it.

Crucially, the readers don't own copies. The fretboard doesn't keep its own little note list; it reads the model's notes and draws frets. The note grid reads the same notes and draws blocks. The voicing diagrams read the model's chords. Pippa grounds her explanations in the model. Easy-mode reads the model and returns a new model — it never mutates the original. One truth, many readers.

Why Copies Are the Enemy

The instant two parts of the app hold their own version of 'the chords,' they will drift. One gets a fix the other doesn't. A re-analysis updates one and not the other. Now the fretboard says E minor and the voicing panel says E major, and the user can't trust either. That divergence is exactly how the predecessor, Guitopia, fragmented — different surfaces built on different representations, none of them the authority. Bonfire's answer is brutal and simple: there is one model, and copying it is forbidden.

The Spine That Holds the App Together

Think of the single model as a spine. Capo-style analysis attaches to it. Easy-mode hangs off it. Every instrument view ribs out from it. The Sidekick reads it. Remove the spine — let each feature grow its own representation — and you don't have an app, you have a pile of features that occasionally agree. The single model isn't a nice-to-have; it's the thing that lets all these surfaces describe the same song.

Code

One model, many readers, zero copies·python

song = MusicModel(
    key="E minor",
    scale="E minor pentatonic",
    chords=[...],          # the progression
    notes=[...],           # notes over a time grid
)

# Every consumer READS the one model. None keeps its own copy:
fretboard.render(song)        # geometry from song.notes + song.scale
grid.render(song)             # blocks from song.notes over time
voicings.render(song)         # shapes from song.chords
pippa.explain(song)           # claims grounded in song

easy = simplify(song, level=1)   # returns a NEW model;
                                 # never mutates `song`

Exercise

Open a multi-panel app you use (a design tool, a spreadsheet, a music app). Find two panels that show 'the same thing.' Now ask: is there one underlying value both read, or two copies kept in sync? Look for the tell — a moment where editing one panel updates the other instantly (one model) vs. a lag or a 'refresh' (copies).

Hint

Instant cross-panel updates almost always mean one shared model. Manual refresh buttons, sync spinners, or 'this view is out of date' banners are the fingerprints of copies.