Accomplishments this week

1. Prepopulation of Web Application Database
  • Our web application was designed to make connections with available pageFlipper hardware first, then ask the users to upload sheet music.
  • Since now it’s not possible to connect with the actual pageFlipper hardware hosted on Raspberry pi, we need to repopulate the database with entries of raspberry pi info for testing purposes.
  • There are several ways to achieve pre-population of the database with Django. (1) To write a migration file and apply migration myself. (2) Use Django fixture to write entries in JSON format and then call Django runPython to load the data into the database before running the server.
  • I tried out both methods and found that using a custom migration files and migrate every time is prone to crash the migration process, and results in inconsistent states between the database and the Django server. Thus, I decided to stick with the fixture approach.
  • In pageFlipper/fixtures, I have written a rpis.json file, which described two entries of available RPIs to repopulate the empty database. To load the JSON data into the database, one can simply type
    python3 manage.py loaddata rpis.json
    and then run
    python3 manage.py runserver
    to start the web server with prepopulated database.
2. TCP Channel between Web Server and MIDI Tracker Program
  • After user uploaded the sheet music onto our web server, the midiTracker program should be able to get the title of the sheet music, with which the program can search for the corresponding midi file in the database and then start the matching process based on that.
  • In order to achieve the communication of the title of the sheet music between the web server and the midiTracker program, I established a TCP channel, where the web server is the client and the midiTracker is the server. They are both hosted on the localhost for now.
  • Before user logs in, the midiTracker has already been served on the localhost and waiting for connections. Once the users done uploading the sheet music, and the image matching algorithm is run to figure out the title of the sheet music, the web server establishes a connection between itself and the midiTracker and sends the title over, and the connection is closed after a reply of SUCCESS is received and the web server end.
3. RestAPI for signaling flip of the page + Ajax for refreshing the template
  • I used RestAPI to handle the flip page signal. Once the MIDI tracker program runs to the point where it thinks the page should be flipped, it sends the flip page signal as a POST request to the webserver. The webserver then updates the Score model with the new page number and image path.
  • To ensure that the user gets a consistent view of the webpage, I decide not to let the whole display page refresh. Instead, I used ajax to fulfill the task of updating the sheet music shown on website. A ajax GET request is sent every 500 ms to see if a flip point is detected. Once detected, the Django views sends the updated information related to the sheet music in JSON format, which then gets rendered on the webpage without refreshing the whole page.
4. Testing using Postman
  • For testing the post request and invalid requests for the implementation of error handling of the website, I used Postman to send requests to the webserver.

Progress for schedule:

  • On schedule

Deliverables I hope to accomplish next week:

  • successfully run the integration on AWS
  • figure out how to read input from MIDI keyboard on AWS

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *