The most significant risks at this stage come from the new features we recently added to our implementation plan: Beat Mode, the Lightweight UI, and Bluetooth transmission. These features are not replacements for existing components but additional functionality layered on top of our original scope. Because of this, they increase the overall system complexity and compress the development timeline. Integrating these additions while continuing progress on the core system introduces schedule pressure and a higher risk of integration challenges.
To manage these risks, we are being more deliberate about incremental integration and testing. Rather than building everything separately and merging at the end, we are validating functionality at each stage to ensure components remain stable as new features are introduced. This reduces the likelihood of large integration failures late in development.
Our primary contingency plan is to fall back to our previously defined MVP configuration if necessary. This ensures that even if advanced features require scaling back, the core system (sheet music processing, note detection, and feedback) remains functional and demonstrable. However, we believe that by increasing our development throughput and maintaining disciplined testing practices, we can integrate these additional features successfully within the current timeline.
The most significant hardware risks at this stage stem from signal integrity issues and potential component failures as we scale the system. Because our design relies on multiple force-sensitive resistors (FSRs) connected to a centralized ESP32, long wiring runs may introduce electrical noise and increased latency in the analog signals. Excessive noise could make it difficult to reliably distinguish between pressed and un pressed states, which would directly impact key detection accuracy and overall system responsiveness. As we expand from small-scale testing to a full 35-key implementation, these risks become more pronounced.
To manage these risks, we are approaching hardware integration incrementally. We will first prototype the sensing system on a breadboard and gradually increase wiring length to evaluate noise levels and latency under realistic conditions. Since the project remains within budget, we plan to order additional components to account for potential hardware failures during testing. If signal noise or latency becomes noticeable during live play, we will transition to a custom PCB design to shorten signal paths and improve electrical stability. Additionally, if FSR reliability becomes a concern, we are prepared to shift to a Hall-effect sensor and magnet-based detection approach, which would provide cleaner digital signals instead of analog resistance values.
Our primary hardware contingency plan is to preserve the LED feedback system even if key detection encounters setbacks. If analog sensing proves unreliable, we can integrate Bluetooth-based communication or pivot to MIDI input from a digital keyboard to ensure accurate note detection. This guarantees that the core functionality of visual feedback and guided learning remains demonstrable, even if the original sensing method requires modification. By planning alternative detection pathways in advance, we reduce the risk of complete system failure while maintaining a functional MVP.
There are no specific updates to the schedule as the software and hardware integration periods will include these new design changes. Work is progressing as planned, with no new visual milestones to report at this time. The Gantt chart (Gantt) outlines the team’s current timeline.