This week we furthered our research and planning process. We thought a lot about the design choices and implementation details. We also considered a lot of alternative ways to implement different functionalities.
Prof. Yu asked many questions during meetings regarding the “why” behind our design choices, so we decided to think hard and justify them – and change them if we couldn’t.
Firstly, we reconsidered the hosting of our web back-end, audio processing and note scheduling logic. We originally planned for it to be on AWS, a decision that would allow us to access much computing power. However, the performance will be bottle-necked by the internet upload and download speeds of each device. An alternative idea is to host it locally on hardware, either a Raspberry Pi or a NVIDIA Jetson Nano. The former is a more familiar device for all three of us, while the latter would allow for more computing power. Both devices would allow us to no longer be bottle-necked by transmission latency. However, we are not yet certain about the physical piano. If our proof-of-concept is unsuccessful and we decide to instead commit to a virtual piano, AWS becomes the best option. Should we stick with the physical piano, we would already have the logic implemented and ready to be migrated onto a Jetson.
We also considered the information retention rate for the audio processing. Initially, we decided to determine frequencies by sampling at exact frequencies to the keys. Upon further consideration, taking into account the number of keys and the total frequency range, we realized that this would result in losing 98% of the frequency. We will instead take the smooth average amplitude of surrounding frequencies to a piano key.