This is the dated build history for SensorSynthFM, an FM synthesizer driven by an iPad's onboard sensors. It replaces a single stale July 1 process snapshot with the full record from inception forward. I keep it because the project's hardest problem was never a shortage of ideas. It was deciding which ideas survived source checks, tests, and physical use.
The record combines public Git history, research and design notes, physical-device reports, publication receipts, and a reviewed projection of the working Kanban board. AI collaborators help with implementation, review, and research synthesis. I own the musical judgment, UX direction, hardware testing, evidence gates, and public claims. That boundary stays visible.
Current Evidence Boundary
The current build has crossed several physical gates. It has not crossed all of them. These are three different states, and treating them as one would turn the page into a sales document.
Physical evidence
July 22 hardware baseline remains verified
The July 22 baseline remains verified: 22 Xcode tests, a generic iOS build, signing, installation, and launch passed on the physical iPad. The August 3 eight-step physical cognitive walkthrough passed seven steps. Play was visible; sound and playing state made sense; the active source and destination were clear; manual control and sensor modulation were distinguishable; microphone response was visible and audible; zero neutralization and recovery worked; and the premise could be stated in one sentence.
Physical interaction
Visual response and route discovery remain open
The failed visual-response step was specific: accelerometer movement changed sound with no detectable visual response, and gyroscope visual response was too subtle to trust. Route discovery also failed because a selected zero route did not look active and creation and removal were unexplained. Open changes are a visible selected-zero state, an explicit route activation explanation, a visible remove control, legible sensor response, all nine sources visible without shrinking touch targets, and testing with users outside this build pass.
Scope boundary
Apple Store visit remains planning only
The proposed Apple Store visit remains planning and scouting only. There are no recorded observations until the research and store-permission boundary is settled. The next build should make the accepted instrument easier to understand before it makes the instrument larger.
Design note · July 17, 2026
The matrix is going to grow.
Nine sources by four targets is the current proof, not the final instrument. The matrix has to absorb more synthesis structure as the engine grows: additional operators, envelopes, LFOs, macros, effects, and destinations. It cannot do that by shrinking touch targets until the interface becomes a desktop routing table under glass.
The July 22 physical capture changed this study from a proposal into the working composition baseline. The next Swift slice should port the matrix-first hierarchy, grouped route inspector, and compact right rail while preserving the accepted behavior and large touch controls. The study records the decision. Swift implementation and physical acceptance remain open.
Interactive design study. Select routes, drag the bipolar amount, use the one-percent nudges, reset through the signed value, switch handedness, and compare the current composition with the revision. This changes the design record, not the SensorSynthFM application.
The screenshots are generated from the working board, then reduced to approved public milestone titles, status, and abstracted work lanes. The current source board holds 1 ready, 6 todo, 2 needs-decision, 56 done, and 2 scheduled cards. The image does not expose private card bodies, comments, paths, logs, or raw identities.
First public board state
The evidence system comes online
Open full-size screenshot ↗This board state established the capstone evidence lane, the physical activation gate, the source-review work, and the first public process page. The precise generation time was replaced by the snapshot date for privacy. The original renderer also clipped the end of the tall Done lane. I kept that failure visible because it explains why the current renderer reserves a stable full frame.
Layout-study milestone board
The evidence workflow gets an honest boundary
Open full-size screenshot ↗This state records the published layout study while the physical route-control refinement was still open. It is now immutable history rather than a mutable current image.
Control-slice milestone board
The physical slice passes and the next proof gets a queue
Open full-size screenshot ↗The July 18 board preserves the accepted control slice, separates full-chain integration from the open composition decision, and makes the Performance-page note-entry definition visible. Two Ready items remain idle until selected.
Current milestone board
Requirements become managed evidence
Open full-size screenshot ↗The August 10 board records the requirements engineering operating model as complete while the physical sensor-mapping evaluation, note-entry prototype, accessibility requirements, and implementation gates remain visibly open.
Build History by Date
This chronology records product behavior, design decisions, research gates, publications, failures, and open validation. It does not inflate internal bookkeeping into progress.
February 2026
FoundationVerified
The Xcode project exists
SensorSynthFM started as an Xcode project, not a product claim. The first commit established the application shell and a source of truth that later design work could be checked against.
Commit 3fd6cf8
Xcode project created
InteractionVerified
The first interface direction is drawn
SwiftUI mockups and supporting project documentation gave the instrument its first visible interaction model. This was still interface intent. No hardware evidence existed yet.
Commit c01d1d6
SwiftUI mockups
Project documentation
SensorsVerified
The sensing layer becomes real
The README established the working project description. SensorManager added microphone permission handling and corrected an FFT memory leak, which turned passive sensing from a diagram into a runnable code path.
Commits 7715ce4 and 2d21827
Microphone permission
FFT leak fixed
AudioVerified
The audio engine makes sound
A sine-wave test proved that the audio engine could run. It was deliberately plain. The point was to establish output before adding FM complexity.
Commit a39ee90
Sine-wave proof
March 2026
DesignDecision
The design record expands
Project notes and design documents were expanded before the synthesis engine changed. The work started to name the intended behaviors, not only the files needed to produce them.
Commit 463a355
Design documents
Project notes
AudioVerified
The proof becomes an FM instrument
The sine wave was replaced by AudioKit's FMOscillator. Carrier frequency, modulation index, modulator ratio, and amplitude became the first real synthesis controls.
Commit 33009ff
AudioKit FMOscillator
Four exposed parameters
IntegrationVerified
Sensors reach the FM engine
SensorFMBridge and SensorFMTestView connected accelerometer magnitude, microphone amplitude, and gyroscope Y to FM parameters. This created the first integrated proof surface for judging whether a physical signal caused an audible change.
Commit 9be8498
SensorFMBridge
Integrated test view
April 2026
DocumentationPublished
The project gets a memory
Public project documentation was added and a project Wiki was initialized. The code, README, design documents, and longer plans had begun describing different versions of the instrument. That was a truth problem.
Commit 02fd220
Public project docs
Wiki initialized
AuditDecision
Activation replaces expansion
The canonical repository and a duplicate starter repository were re-audited. The next gate became physical activation of the existing integrated view, not another feature branch.
Repository audit
Duplicate starter identified
Activation checklist
InteractionDecision
A larger interaction system is documented, then held back
Touch-native looping, sequence and edit grammar, rhythmic capture, and a three-page architecture were documented. They stayed behind the activation gate. The design could grow after the physical proof, not instead of it.
Looping direction
Three-page architecture
Activation still first
June 2026
RestartDecision
The build restarts from the device
The restart plan narrowed the work to physical activation. GitHub and the canonical repository remained code authority. Google Drive remained an archive and handoff surface, not a place to run the project.
Physical activation gate
Canonical repo restored
Drive kept archival
CapstoneVerified
Research and the task board are connected
The desk-research inventory and active build questions were connected to the working task board. The long-running Kanban structure was prepared as the operational evidence trail for research, implementation, review, and parked scope.
Public source inventory
Build questions connected
Capstone board prepared
July 2026
HardwareVerified
The integrated app runs on a physical iPad
The app entry was changed to SensorFMTestView. James ran the integrated build on a physical iPad and confirmed sound output plus audible accelerometer and gyroscope mappings. The microphone seemed active, but the response was too subtle to trust.
Commit 6a7683f
Sound passed
Motion mappings passed
PublicationPublished
The evidence trail becomes public
The desk-research page and first process page were published with a 33-card Kanban capture. Capstone evidence, discovery questions, source review, parked ambitions, and the usability-video privacy boundary became explicit parts of the build record.
33-card board state
Desk research published
Process page published
ResearchPublished
The public source trail catches up
Repository documentation drift was corrected and the SceneFingerprint implementation packet was clarified. A source atlas built from 319 reviewed public URLs was published so the research surface could be inspected before it was narrowed.
Documentation corrected
319 public URLs
Source atlas published
EvaluationDecision
Listening changes the mapping priorities
Physical listening ranked the gyroscope first and the accelerometer second. The microphone was alive, but it needed a different interpretation. Accessibility requirements, an interaction model, a cognitive walkthrough, a moderated usability script, and findings-to-decisions traceability were documented around that evidence.
Gyroscope ranked first
Accessibility requirements
Evaluation plan
ImplementationOpen
Three repairs enter review
Microphone diagnostics, safe-area and control-authority repairs, and SceneFingerprint implementation moved into review lanes. The public project narrative was corrected at the same time so the page stopped promising a fixed routing model as the finished direction.
Microphone diagnostic lane
Control-authority repair
SceneFingerprint review
ScopeDecision
The demo becomes stationary
The current focus narrowed to one convincing two-minute environmental-modulation demo with the iPad resting on a table. The project stopped treating whole-device motion as the main performance gesture. This is room and surface modulation, not keytar behavior.
Two-minute demo
Stationary iPad
Environmental modulation
DiagnosticsVerified
The microphone and scene model reach hardware review
Microphone diagnostics and a SceneFingerprint proof harness were assembled on a review branch. Xcode tests and a generic iOS build passed. James cleared the signing boundary and reported that the microphone responded on the physical iPad.
Xcode tests passed
Generic iOS build passed
Physical mic response
InteractionVerified
The fixed mapping becomes a matrix
A touch-first modulation matrix was implemented with nine sources, four targets, 36 bipolar route cells, editable base values, and migrated defaults. Seventeen Xcode tests and the generic iOS build passed. James reported physical signing, installation, and launch success, while per-route interaction behavior remained under review.
9 sources by 4 targets
17 tests passed
Physical launch passed
HardwareVerified
The microphone passes, then the interface fails
James ran a two-minute stationary microphone test in a room measuring roughly 60 dB. The route was audibly causal, stable, and only slightly pumping, although exact calibration remained open. The same physical pass exposed a blocking defect: the route slider occupied the iPadOS bottom gesture zone.
Two-minute physical test
Causal mic route
System-gesture conflict
ImplementationVerified
The first route-editor repair reaches review
A local adaptive route inspector defaulted to the right, mirrored for left-handed use, moved diagnostics behind progressive disclosure, and added a center-zero control with one-percent nudges and a zero detent. Source checks passed. The next physical review rejected its fixed side rail, turning this implementation into evidence for the redesign rather than a finished interaction.
Adaptive inspector implemented
Source checks passed
Physical review next
HardwareOpen
The iPad rejects the side inspector
The repaired build reached the physical 11-inch iPad with the selected route fixed at the right edge. That solved the wrong problem. The 300-point rail made the primary bipolar slider too narrow for confident touch control and left most of the right column unused. The next layout must put a wider slider directly below the matrix and reserve the right rail for secondary elements.
Rejected physical layout. The route amount control occupied a narrow right-side inspector, but iPad testing showed that the primary slider needs a wider strip below the matrix. The iPad status bar is redacted. This records the defect, not a completed repair.
Physical iPad capture
Side inspector rejected
Full-width slider required
InteractionDecision
The wider editor reaches the iPad, and the grid is still not done
The selected-route editor moved below the matrix. Twenty Xcode tests, a generic iOS build, and simulator geometry checks passed before James signed, installed, and launched exact commit c5d3472 on the physical 11-inch iPad without errors. The physical review was clear: the revision is better, but it still underuses the available space. The dedicated ZERO control wastes room, the plus/minus nudge order must reverse, and the grid should move toward an Ableton-like layout over time. The next interaction revision remains open.
Commit c5d3472
20 Xcode tests passed
Physical launch passed; layout still open
EvidenceDecision
The screenshot path is corrected before it becomes another claim
A live check confirmed that Xcode 26.3 still sees the physical iPad as paired. The working capture path is Window > Devices and Simulators, where a human takes the full-resolution screenshot before the existing transfer, sanitization, privacy review, and publication pipeline runs. Apple's newer Device Hub remote-control instructions do not apply to the installed toolchain. Agent-operated physical UI-test capture remains proposed, not implemented.
Xcode 26.3 pairing reverified
Manual capture path corrected
Automated physical capture remains open
DesignPublished
The matrix gets a layout study before it gets more synthesis
The physical rejection became an interactive current-versus-revision design study. The revision keeps all nine current sources visible, gives the selected route a wide bipolar strip below the grid, reverses the nudge order, turns the signed amount into the reset target, and reserves the right rail for secondary context. The harder constraint is growth: nine sources by four targets is the current proof, not the final ceiling. The matrix has to expand with the synth without collapsing touch targets or burying route editing.
Interactive layout study
All nine current sources visible
Matrix growth remains an open design constraint
HardwareVerified
The quick control slice passes, and the next proof is named
Exact commit 635ab09 removed the dedicated ZERO control, reversed the default nudge order, and made the signed amount the reset target. Twenty Xcode tests, a generic iOS build, installation, and launch passed before James confirmed all three requested controls worked on the physical iPad. The larger web-study composition is still not in Swift. The new board keeps that decision open while making full-chain integration, note-entry definition, walkthrough, mapping survival, and the capstone evidence brief visible in sequence.
Commit 635ab09
20 Xcode tests passed
Three physical control checks passed
July 18 board archived
HardwareVerified
The atomic handoff survives the iPad
A corrected integration pass produced exact commit 48b6b3d. It replaced separate microphone reads with one coherent snapshot and moved sensor startup into the application runtime. Twenty-two Xcode tests and the generic iOS build passed before Xcode signed, installed, and launched it on the physical 11-inch iPad. James confirmed that sound, accelerometer and gyroscope response, and microphone response all worked as before. The screenshot below records the visible composition. It does not replace the physical behavior report.
Accepted physical build, unfinished composition. Xcode and direct physical checks established behavior. This image records the visible native layout: the ninth source needs horizontal swipe, part of the context rail falls below the fold, and the selected-route controls span more space than they need. The iPad status bar is redacted.
Commit 48b6b3d
22 Xcode tests passed
Physical sign, install, and launch passed
Sound, motion, and microphone rechecked
DesignDecision
The physical screen earns a partial port
The physical capture was normalized against the existing 1210 by 834 public study. The native screen keeps large, reliable touch controls, but it clips the ninth source, leaves context below the fold, and separates the signed reset value from its nudge controls. The working decision is a partial port. Existing modulation behavior stays. The matrix-first hierarchy, grouped route inspector, compact right rail, reset explanation, and progressive-disclosure diagnostics move into the next layout brief. That Swift composition has not been implemented or physically tested.
Point-matched physical comparison
Partial port selected
Swift composition still open
August 2026
EvaluationVerified
The physical walkthrough passes seven of eight steps
The eight-step physical cognitive walkthrough passed seven steps. Play was visible; sound and playing state made sense; the active source and destination were clear; manual control and sensor modulation were distinguishable; microphone response was visible and audible; zero neutralization and recovery worked; and the instrument premise could be stated in one sentence.
Seven of eight walkthrough steps passed
Physical iPad walkthrough
Zero neutralization and recovery passed
DesignOpen
The failed visual response names the next build
Accelerometer movement changed sound with no detectable visual response, and gyroscope visual response was too subtle to trust. Route discovery also failed because a selected zero route did not look active and creation and removal were unexplained. The next changes are visible selected-zero state, explicit route activation explanation, visible remove control, legible sensor response, all nine sources visible without shrinking touch targets, and outside-user testing.
Accelerometer sound change without detectable visual response
Gyroscope visual response too subtle
Selected zero route did not look active
ProcessDecision
Requirements become managed evidence
Stable requirement IDs now connect stakeholder outcomes, system behavior, qualification evidence, Kanban work, and dated history. The public section is a projection, and implementation success alone does not qualify a stakeholder outcome.
Seven-requirement public projection
Requirement and qualification contracts on consequential Kanban work
Explicit pass/fail/unqualified status model
How This Stays Current
This page is event-driven. It is not a real-time board dump and it does not update on a timer. A timer can copy a status. It cannot decide whether a code change earned a public claim.
Every verified public milestone now closes through the same history gate. James's July 15 request is standing approval for narrow public-history refreshes that pass this sequence. It is not approval to publish unrelated code, unpublished project material, participant material, or unsupported claims.
Step 1
Verify the milestone
Start with the strongest evidence available: Git, Xcode output, a physical-device report, a research artifact, or a live publication receipt.
Step 2
Update the dated record
State what passed, what failed, and what remains unverified. Classify each new board title before any part of it can reach the public screenshot.
Step 3
Regenerate and inspect
Produce the current board image and a date-keyed archive, then run the privacy guard, typecheck, lint, and production build. A timer cannot do this judgment.
Step 4
Publish and prove it
Verify the source workflow, public Pages workflow, live route, and image URLs. Internal smokes, retries, bookkeeping, and unverified code churn do not earn a history entry.
The Commitment
I will keep documenting what survives physical use, what fails under a hand, and what stays open after the code looks finished. The device gets the last word.
