One of the most significant risks in our project is our reliance on WebSockets to deliver packets of audio, and our expectation that Django will work kindly with the packets. We know from experience that Django has built-in measures to handle file uploads in very particular ways (for security purposes), and sending audio data packets with WebSockets to a Django web app server is not something there is very much information about on the internet. To add to this, none of us have prior experience using WebSockets. In order to mitigate this risk, we plan to do some experimentation with WebSockets before we fully specify the design for our project, to determine if this approach is feasible. As a contingency plan, if sockets cannot be used, we know for sure that the audio can be recorded in-browser, and sent afterwards to the server as a complete file in a multipart form-data upload. However there are many drawbacks to this approach. This would require a large file upload at once (CD quality wav audio files get large very quickly), but perhaps more importantly, there is no possibility for audio to be streamed “live” to other musicians or spectators.
The only major structural changes made to our design this week have been narrowing the scope of the project from our initial abstract as we created our project proposal slides. We have set more specific guidelines for the project, which can be found on slide 2 of the proposal slides. Our schedule has not changed, since the proposal slides contain the first draft of our timeline (slides 11 and 12).
Aside from that, we have each done our share of research for our specific areas of the project: Jackson in audio processing and file uploads, Ivy in synchronization and Django, and Christy in UI and audio visualization.