9/14/18
- Videos
- Spoken Word: https://youtu.be/vnKZ4pdSU-s
- I thought it was interesting because he uses a lot of gestures while he performs, which I don't see too many spoken word artists do
- Very emotionally charged words
- Lots of movement in his upper body and arms
- Very obvious what emotion speaker is feeling from watching just the gestures and/or just listening to speech
- Jeff Goldblum: https://youtu.be/_l4xtcmrT6g
- Picked him because he has very odd mannerisms; doesn't finish sentences, restarts his train of thought with new sentences including new details
- 0:28 - Explicit description of what "fumfer" is, intentional stuttering or rambling
- 0:54 - Uses gestures to mimic the actions that he's talking about (driving)
- Daria: https://youtu.be/HdZsqZKT3oY
- Picked this clip cause I think she sounds like Siri
- Thought I would pick a clip that involved animation
- 0:05 - Doctor only has movement with his eyes/eyebrows but you can still obviously tell the kind of vibe he's giving off (bewilderment)
- Even though she's very monotone/emotionless, the show relies on very minute changes in animation/tone to show emotion
- Read through PyPot and Dynamixel MX-28 documentations
- Dynamixel MX-28
- Didn't understand this one that well because it used a lot of hardware terminology that I was not familiar with
- Understood some of the error messages
- Most important part of the motor documentation - control table
- PyPot
- Understood this one a lot better because I'm familiar with coding in Python
- Read through the Dynamixel Low-Level IO instructions and some of the other links listed under "tutorial"
9/21/18
- Looked through GitHub repo that was shared to us last week
- Looked through and tried to understand what was going on with the code in RecordShimiGestures-checkpoint.ipynb
- Wasn’t that bad to read because each chunk of code was split up into different sections
- Also looked through the hardcoded “Hey Ya” demo for gestures
- Looked through some of the code under the legacy code to see old Shimi code
- Worked a little bit more with getting used to git (I’ve only used it a little bit before) in general
- Read through article posted under the Shimi group on the Google site
- I thought that Figure 6 was interesting because it goes through the whole process of how Shimi decides on what emotion it wants to express through its five available degrees of freedom
- Elaborated on in Figure 9
- Uses available degrees of freedom (head, legs, etc.) to express emotions you would usually show through facial expressions
- Revisited PyPot documentation to read over it and refresh my memory
- Tried to go back to the Dynamixel documentation and understand it a little bit better
9/28/18
- Spotify API mini-project
- Given on 9/24
- Shimi gives the appropriate auditory response when the user asks if they would like a certain song
- Based on Spotify listening history/recommendations
- Gives a score from 0 (would not like) to 1 (would like) on how much it matches user’s taste
- What I already know from using Spotify myself
- Discover Weekly gives you a playlist of recommended tracks based on your listening history on the whole (not on one particular track though)
- Can create radio stations based on particular tracks
- Can say whether or not you like the track in the station to tailor the suggestions to your taste
- REST/RESTful API
- Uses HTTP for web APIs
- No need to install libraries/additional software to use REST API
- Can handle different types of calls and can return different times of data formats
- Can return XML, JSON, YAML, etc.
- Spotify developer documentation - getting recommendations
- Only effective for artists that have enough data that Spotify can generate recommendations
- Harder to do with newer/more obscure artists
- Endpoint: GET https://api.spotify.com/v1/recommendations
- Query parameters:
- seed_tracks with the track in question (input is Spotify IDs) (?)
- Can provide up to 5 values
- target_*
- Can request things such as target_energy=0.6 and target_danceability=0.8 to see which tracks have attributes nearest to the inputted values
- min_* and max_*
- Hard ceiling and hard floor for certain attributes
- Ex. - min_instrumentalness=0.35
- Ex. - max_tempo=140
- See how many tracks you have saved match the target_*, min_*, and max_* inputs of the inputted song (?)
- Spotify Web API
- Spotify Web API endpoints return JSON metadata on artists, albums, and tracks
- Also provides access to user-related data (playlists and saved music on a user’s profile)
- Calls to Web API require user authorization
- Spotify Authorization
- User authorization - user grants app permission to access/modify user’s data
- Call to /authorize endpoint and passes it along to list of scopes that require access permission
- Python wrapper: https://github.com/plamere/spotipy
- Documentation: https://spotipy.readthedocs.io/en/latest/
- Authorization code flow - user logs in once, gives an access token that can be refreshed
- Inputs that can be used in the wrapper:
- Spotify URI - resource identifier that you can use with Spotify desktop app
- Ex. - spotify:track:6rqhFgbbKwnb9MLmUQDhG6
- Spotify URL - HTML link that opens in a Spotify client
- Spotify ID - base 62 number at end of URI
- Ex. - 6rqhFgbbKwnb9MLmUQDhG6
10/5/18
- Met with Cameron to discuss how we wanted to start Spotify Mini Project
10/12/18
- Met with Cameron to work on code for Spotify mini-project
- Created a project in the Spotify developer's dashboard to generate a client ID and secret ID
- Should find a way to generalize this authorization method? I don't know if this is the right way to do it, but it works for now
- Used Spotipy examples from the GitHub repo as a starting point
- Created a first iteration which takes an input of two tracks, compares 8 track features, assigns each feature a weight, and returns a float from 0 to 1 on how much the user would like the song
- Track IDs and track feature weights are hardcoded
- 8 features: energy, valence, instrumentalness, danceability, acousticness, duration, loudness, and speech
- For the future, things to work on/improve:
- Instead of hardcoding in the track IDs, incorporate search endpoint so that, within Python code, user can input a string of the song title to search
- Get the main input to compare to a list of user's top tracks rather than just one track (using the Spotify endpoint which gets user's top tracks)
- Improve the functions that we use to weight each track feature
- See how we can translate the float output into a gesture that Shimi performs
10/19/18
- Implemented search function into the code
- User inputs song title and artist separately, and Spotify uses the first search result as the inputted comparison track
- Limited the search results to whatever the first track was because:
- 1. There's no real reason for the function to return 10 searched tracks if it's only going to use one?
- 2. It cut down on run time significantly
- Doesn't account for spelling errors, so the user has to put the track and artist name in exactly
- Modified our weighting functions so it returned more realistic "likelihood you would like this" output
- Before we changed it, most tracks were in the ~0.9 range even when the tracks were drastically different
- For next week, work on setting the comparison to be user's top tracks
- Don't know how many tracks I should include in the top tracks because if I have more tracks, that would increase overall run time
- From what I can tell by the top tracks example in Spotipy, it returns the top tracks as a playlist, so I need to figure out how to get track audio features (for each song) from a playlist
10/26/18
- Practiced using Git/Github
- Downloaded desktop client to learn how to use that properly in conjunction with Git Bash
- Cloned Shimi repository and played around with Git commands
- Started working on project code, but ran into issues
- Tried replacing sys.argv with argparse as was suggested
- In reference to username input for authentication method
- Couldn't figure out how to work around client_credentials module
11/2/18
- Added in client_credentials module with my developer credentials
- Authorization works, yay!
- Replaced hard-coded second track with a API call that gets user's top tracks
- Can indicate how many tracks you want
- Can indicate range of listening history (short, medium, or long)
- Currently, I have a dictionary totalling up the audio features of each of the top tracks and averaging them
- Cleaned up superfluous code and corrected it to fit coding conventions using pycodestyle and pylint
- For next week
- Work with Cameron on finding a better way to compare the input track to the user's library
- My average method isn't really that effective
- Figure out how to cache the info from the API call at the beginning so that it won't take as long for the code to run while comparing song information
11/9/18
- Tried to work on a way to cache the API information the first time you run the code so that the subsequent runtimes will be shorter
- Think I still need to work on this because I'm not sure if it's actually doing it correctly
- Worked on 3/4 presentation with Cameron
11/16/18
- Didn't do much coding this week, but I read up on different ways to implement a spell checker/spelling suggestion function into the search endpoint
11/30/18
- Worked on improving the cache system because I'm not sure it was working correctly
- Think I made improvements to it, but I want to figure out how to use Redis to cache information
- Will work on spellchecking by the presentation time next week