The problem was not lack of ideas
SensorSynth FM 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.
The repo already contains a real AudioKit FM prototype, a real SensorManager, a real SensorFMBridge, and a real SensorFMTestView. The integrated lane exists. But the app still boots into FMTestView, not the integrated sensor-plus-FM view. So the project is not mockup-only, and it is also not at the finish line.
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 Discord updates 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 SensorSynth FM 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 happens next
The immediate next step is not another rewrite. It is to activate the integrated sensor-plus-FM lane, test it on actual hardware, and record what remains true after that test. If the wiki does its job, it will keep the project from disappearing into ambition again.
The public docs layer is still in progress.
You can read the case study for the broader design framing at SensorSynth FM.