Team Status Report for Apr 29

Summary 

This week, the team finished most of the development necessary for our project. We were able to get all our individual subsystems working and we were able to integrate them together. Next week, we are going to be completing our testing and optimization so that we are ready in time to demo our project the week after. 

Tests

There were a various tests done on an individual subsystem level and at the project level throughout the development process. 

Signal Processing

1. Song Recognition – We tested 15 different songs from Billboard’s top 100 playlist and the song recognition was able to accurately identify each of them with a 5 second clip
2. Functionality Tests – Isolated individual features and tested them against a hand labeled file. Deployed commands based on these outputs to the lights, and checking alignment. 

1. Latency tests – Used python time to measure latency and realized real time processing was causing major delays and reduction in accuracy. Opted for preprocessing instead, which allowed us to play music in line with the lights. 
2. Global Parameters – Extracted and used them for logic, but were able to extract similar information directly from the signal processor. Scrapped this use for the logic, and rather used this for the recommendations in the UI.

Lighting Engine

1. Functional Testing – Sent dummy commands to each individual light and different light sets. Were able to address each light individually and a group of lights.
2. Concurrency Testing – Sent dummy commands to simulate race conditions and addressing multiple lights simultaneously. Failed the first time, but were able to implement this using thread locks.

Logic 

1. Log Files: Created 5 different log files – rotation speeds, colors, time, functions, and lights. Manually inspected the log files and combined these to produce commands for the lighting engine. Were successfully able to send commands to the engine and deploy them on the lights. Were initially sending a sequential list of commands, but upon testing the outputs, we realized that each light had to be addressed individually in order to implement concurrent execution. Example log for rotation direction and speeds for two beats.

1. Plots: For interim testing of the logic functions, matplotlib plots were generated. This was a low effort testing solution to test quickly without needing to deploy everything on the lights. For instance, color of strobe was analyzed across the duration of the song, as shown. Further, change point detection and running averages were implemented to analyze the signal processing outputs using time series analyses.
   

UI and User Tests 

1. Webapp Deployment – Tested deployment of various features to the webapp, making sure that the system didn’t crash. Initially implemented sliders for global parameters, but following logic testing, we scrapped these in favor of individual real time commands. 
2. Manual Override – Were able to send packets of information directly to the queue and were able to force the queue to execute these commands on the next beat as opposed to the default command from the logic. 
3. User Feedback – Tested the system with 4 users without any technical expertise. Made sure that the webapp was intuitive enough for people to get familiar with quickly. 

Integration

1. Setup time: Tested with 4 users without any prior experience and everyone was able to achieve setup within 5 minutes, using minimal guidance. 
2. Logic/Lighting Engine: Sent packets of information to the lighting engine and executed those commands as they were received. Tested this functionality for the entire length of a song.
3. UI/Lighting Queue: Synchronizing user commands with the lighting queue for the length of a song. Given a command, we were able to synchronize it with the next beat for the entirety of the song.