The problem was not lack of ideas
SensorSynthFM already had plenty of ambition: passive sensing, embodied interaction, FM synthesis, environmental modulation, camera and motion inputs, live performance, a broader research frame around musical expression. More features were not the hard part. The hard part was knowing which claims were still true.
By the time I stopped to audit it, the project had several layers of truth sitting on top of each other. The live Swift files showed one reality. The README described an older one. The planning docs described a larger future. All of them were useful. None of them were interchangeable.
What the audit actually found
The most important finding was simple: the codebase is ahead of the README and behind the master plan. That one sentence explained most of the confusion.
At the time of this audit, the repo already contained a real AudioKit FM prototype, a real SensorManager, a real SensorFMBridge, and a real SensorFMTestView. The integrated lane existed, but the app still booted into FMTestView rather than the integrated sensor-plus-FM view. The later hardware milestones are recorded in the public build history.
That matters because the project bottleneck is no longer “start building someday.” The bottleneck is “activate and validate the thesis-demo lane now.”
The wiki changed the question
Before the wiki, the project encouraged the wrong kind of thinking. Every time I looked at it, I could ask for another feature, another system, another input modality. That is how ambitious work turns into sludge.
The wiki forced a better question: what is the next milestone that actually matters? The answer was not “finish the whole instrument.” It was “produce a one-screen thesis demo where passive or lightly active sensing audibly and visibly shapes FM timbre in a way that feels musical, intentional, and easy to explain.”
That is a much better target. It is bounded. It is testable. It is honest about the fact that interaction has to survive contact with reality, not just read well in a design document.
Why a wiki instead of more notes
Chat logs and dated handoffs are good at preserving chronology. They are bad at preserving durable truth. A wiki does the opposite. It answers the questions future-me will actually ask: what does the prototype do right now, what is stale, what decisions are settled, what research matters, and what should happen next.
That distinction matters more on AI-assisted projects. When part of the implementation loop is distributed across handoffs, prompts, repo docs, and code generation sessions, the documentation layer is not decoration. It is part of the system design.
What the public version should be
I do think SensorSynthFM deserves a public documentation surface. This project benefits from open development. The right public shape is not a giant note dump. It is a curated project wiki: thesis demo definition, architecture notes, key decisions, research map, and milestone updates that explain how the instrument is evolving.
That is useful to collaborators, hiring managers, other creative technologists, and honestly to me. It makes the project legible. It gives the case study a proof surface instead of asking visitors to take my word for it.
What happened next
The integrated sensor-plus-FM lane was activated and tested on a physical iPad after this note was published. The microphone, motion, and modulation-matrix evidence now lives in the dated build history, alongside the failures and open interaction decisions.
Read the current build history.
You can read the case study for the broader design framing at SensorSynthFM.