Posted on

Team Status Report for Feb 14

  • Week 2 Status Report Requirements: Part A was written by Simon, B was written by Gene, and C was written by Chris.

One of the most significant software-side risks is system latency, particularly in Beat Mode where LED updates must remain synchronized with user-defined BPM. Excessive processing time during conversion, JSON transmission delays, or timing jitter on the microcontroller could result in visibly inaccurate or unstable LED guidance. To manage this risk, the architecture separates preprocessing (image conversion and quantization) from real-time playback, ensuring all heavy computation occurs before transmission. The system also uses fixed 1/16-note quantization to simplify timing logic.

This week, the software architecture was updated to explicitly support two operating modes (Beat and No-Beat) and to integrate a Streamlit-based UI into the Core Layer. The change was necessary to better align the implementation with the defined use-case requirements—specifically, supporting both note-learning and tempo-synchronized practice. Additionally, the conversion layer was refined to include a Raw Event Intermediate Representation to improve modularity and testability. The primary cost of this change is increased architectural complexity and additional development time for mode handling and UI integration. To mitigate these costs, the system has been organized into modular components with clearly defined data interfaces, enabling incremental implementation and reducing integration risk going forward.

There have been no updates to the schedule. 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.

Posted on

Chris Oh’s Status Report for Feb 14

This week I focused on refining the software architecture and transitioning from high-level design into early implementation. I expanded the system design to incorporate both Beat and No-Beat modes, further specified the responsibilities of the conversion layer, and began prototyping the overall software framework. In parallel, I prepared materials for the upcoming design presentation.

Software Architecture Updates

  • Refined and updated the software architecture to explicitly support two operating modes: Beat Mode and No-Beat Mode.
  • Expanded the conversion layer design by clearly defining:
    • Raw Event IR structure
    • Quantization process for Beat Mode
    • Key mapping logic (MIDI → 88-key index)
    • JSON payload generation for hardware transmission

  •  Integrated a Streamlit-based UI into the Core Layer design to support:
    • Image upload
    • Mode selection
    • BPM input
    • Play/Pause controls
    • Status feedback

  • Ensured that the updated architecture maintains modular boundaries and allows independent testing of:
    • Image-to-MusicXML conversion
    • MusicXML parsing
    • Event processing
    • Hardwarecommunication

Design Presentation Preparation

  • Prepared slides and technical material for the design presentation.
  • Refined system diagrams to reflect:
    • Updated pipeline stages
    • Mode branching logic
    • Software-hardware interface definition

Week 2 Status Report Requirements: Part C

From an economic standpoint, LumiKey is intentionally designed to remain affordable and practical. The hardware uses commonly available, low-cost components such as an ESP32 microcontroller and addressable LED strips, which keeps overall system cost reasonable. On the software side, we rely on open-source tools like Python and music21, avoiding licensing fees and making long-term development more sustainable. Because the system is designed to attach to a standard piano or keyboard rather than replacing it, users do not need to purchase a specialized instrument. This approach helps keep the product accessible to students and families who may already own a keyboard but are looking for a more guided learning experience.

Schedule

I am currently on schedule. The architecture has been refined to include mode logic and UI integration, and the foundational software framework has been established. The project is transitioning from planning into active implementation.

Deliverables for Next Week

  • Implement core functionality of the conversion layer (MusicXML → Raw Event IR → chord grouping).
  • Begin implementing Beat Mode quantization logic.
  • Establish and test JSON transmission pipeline to the hardware layer.