The numbers said the music was improving. My ears said noise.
Twenty-four generated pieces were measurably different, yet three listening samples were enough to reject them because better metrics could not explain why the music felt wrong.
Twenty-four generated pieces were measurably different, yet three listening samples were enough to reject the whole direction. That mattered because Mapsonata was supposed to make places audible: using TypeScript and the browser's Web Audio API, I was turning geographic coordinates into music that was deterministic enough to replay, while Montevideo and Cape Town still needed identities a listener could actually notice or the map would only be decorative.
By the fourth candidate, the test suite could show twenty-four different opening patterns across eight musical styles, so on paper the system was improving. However, the listening review collapsed that confidence within three samples: the beat was hard to follow, different parts seemed to move at different speeds, and the notes did not feel as though they belonged to the same song.
The metrics showed variety, but my ears heard noise, which exposed the mistake: I had allowed “different” to become a substitute for “worth listening to.”
The dashboard was answering the wrong question
The early music was coherent enough to recognize but dull, so later versions introduced more movement, broader pacing, different arrangements, and more distinctive lead patterns.
By the fourth candidate, the engine could prove that all 24 fixture plans had different pitch-independent lead openings, while eight curated archetypes connected groove, form, arrangement, motifs, palettes, and density. Additionally, bass, chords, percussion, and counterlines were derived around a lead rhythm instead of behaving like completely unrelated generators.
Those were legitimate improvements because they answered whether the software could create reproducible difference without obvious collisions or broken playback, but they did not answer whether anyone would call the result music.
What the numbers proved
- Every place regenerated the same plan
- Fixture openings were measurably distinct
- Events stayed within valid timing and output limits
- Supporting parts avoided obvious collisions
- Playback could start and stop cleanly
What three listens revealed
- The pulse was difficult to follow
- Parts suggested competing speeds
- Phrases lacked a clear hierarchy
- Variation did not create a shared identity
- The result felt assembled, not performed
This is a common failure in generative products because a proxy becomes easier to improve than the experience it was supposed to represent. More unique layouts can look like design progress, more varied paragraphs can look like writing progress, and more distinct melodies can look like musical progress.
The system gets better at passing its own test while the user gets better at noticing that the test is incomplete.
“Make it more musical” was true and useless
The obvious next move was to build candidate five—adjust the parameters, enlarge the pattern library, generate another batch, and listen again—but that would have produced more music before the project had a precise way to discuss why the existing music failed.
“It sounds like noise” is important feedback, though it is not yet an implementation plan. Was the drum foundation too weak? Did the bass fight the beat? Did the harmony flatten the phrase? Did the lead introduce a second rhythmic language? A finished mix made all of those possibilities audible at once and editable in none.
So generation stopped.
The next useful artifact was a small calibration bench with four deliberately authored rhythmic identities, each exposed one layer at a time. A listener could hear the drums and bass first, then add harmony and one lead, while stopping the review at the first layer that damaged the pulse.
- Hear only the rhythmic foundation
- Add harmony and listen for a damaged pulse
- Add the lead and listen for competing motion
- Stop at the first layer that feels wrong
- Edit the shared four-bar pattern directly
- Export the exact session for the generator
The editor uses a four-bar sixteenth-note grid where drum cells toggle directly, bass and lead steps expose scale degree, octave, duration, and velocity, and chord roots and tempo can be changed. Reviews remain in local browser storage and can be exported as readable pattern text and machine-readable JSON; nonetheless, this is not a finished composition tool, but a narrower way to let a human correction land somewhere more useful than another prose prompt.
The product needed a language for disagreement
The calibration bench changed the user's role because, instead of judging a fully generated result at the end, the listener could point to the foundation the system should preserve and the exact layer where coherence disappeared.
That is more valuable than producing ten more options and asking for a favorite because selection tells the system which output won, whereas calibration starts to explain why.
The distinction matters beyond music because, whenever a product depends on taste, quality, or judgment, automated variety can hide the absence of a shared evaluation language. The answer is not always another model or another generation; sometimes it is a small interface that makes disagreement inspectable.
As of this Note's publication date, the calibration bench passes its structural, playback, editing, and responsive-layout checks, but its default musical patterns have not passed listening review. Gate 1 therefore remains failed, and there is no evidence yet that the bench has improved generated music.
The numbers were not wrong: they proved the music was different, but the listening review revealed why that was never the same as proving it was good.