Music Notation and Data Visualization

I was learning a song from a Youtube video today, and found myself rewinding to watch the same few chords being played multiple times. The student in me started writing the chords down, except I used the “letter names” of each note instead of the normal “music notation” on a staff.

A notebook with the letter names of notes written on them lying on top of a Yamaha keyboard

As I was playing along to the video, I realized that I process this type of notation a lot slower than the “normal” music notation, where notes are represented by circles on a staff, and I can “guess” at the type of chord I’m playing just by the shape of the chords on a staff.

The letters above were arranged from low notes to high notes, but because I didn’t make use of distance, mapping the distance between notes to actual distance on the keyboard, I had to read each letter individually. It’s a lot more cognitive work to read each letter individually, as opposed to approximating pitches based on a visual map.

A certain clustering of notes tells me to expect a “major” chord, and another tells me to expect dissonance, and having played for long enough, these reactions happen almost intuitively.

I’m a decent sight-reader, but I rarely read every note on a staff anymore. Instead, I’ll look at the first couple notes, and judge the melody lines based on their altitude: whether the notes seem to be moving up or down. The representation of the music notes allows me to make

At work, we do a lot of exploratory data analysis and visualization, and on occasion, will create custom representations of complex datasets. The connection between the two just occurred to me today: that the same way I use “pattens” in a symbolic representation of notes to make rapid inferences and decisions about where I place my hands and how to move around the keyboard, when we design dashboards for high-level overviews, we’re enabling this kind of inference.

The flip side of visual representations assisting us with quick inferences, though, is that the representations that we choose shape and constrain the narratives we’re able to access most easily. When I’m looking at the “shape” of a line of music, I guess approximately where it is on the piano,  what the “next step” my fingers should be taking, and what sound I should expect.

However, when a piece of music has highly chromatic scales (lots of notes moving in close proximity, and deviating from what I expect them to sound like), and tightly clustered chords (making the visual clutter of a chord harder to parse quickly), there are times I consider alternate representations. In fact, even if I don’t fully build it out, that’s usually how I grok a difficult passage of music: by notating it differently, and annotating the score with symbols and words that tell me what to expect and linking it concrete past experiences.

Who knows – I might build this out into a longer series of blog posts considering data visualization and representation through the lens of a musician.  For now – I think I’ll put a post-it with a couple music notes on it, to remind me of the importance of visualization, representation and mapping when I’m lost in the code and statistics of my data.

Intro to Python for Data Science

Earlier this year, I had the opportunity to give a 30 minute water cooler talk to the NASA Datanauts cohort. I spoke on an Introduction to Python for Data Science.

This is the link to the github repository.

I have a couple slides that are introduction to Python and some object-oriented concepts, but that’s not why I’m writing this post. Instead, I’m going to talk about the approach I took when I was thinking about this tutorial.

It seems like anywhere I look, I can find good tutorials on how to perform certain manipulations in Pandas, or do some plotting in Matplotlib, and those tutorials are often written and presented by people who are much more familiar than I am with the technology at hand.

Instead, I was interested in presenting the things I didn’t find easily on the Internet.

How do people debug?

How should I think through a problem?

I wanted people to come away with a sense of what to do when they got stuck, and how to interrogate problems. To provide that toolkit, then, I introduced the tools, then walked through as much of a “real-world” data science problem as possible.

The toolkit I described included:


dir(obj) allows one to interrogate the properties and methods of an object.

The inspect module is literally magic. I first encountered it at a coderetreat, where it was used in a (quite antagonistic) pair programming session. Since then, I’ve worked on a lot of projects where a quick inspect.getsourcelines(obj) lets me see what’s happening under the hood, and it’s much faster than finding the documentation on Google.

Last but not least, reading the source code, of course! One of my recent hobbies has been to go to Github to read the python source code of whatever module I’m having trouble with. Often, by understanding what inheritance patterns look like and reading class definitions, I’m able to get a better sense of the logic behind the codebase and choices that were made.

Since I gave the talk, I’ve added a couple more things to my toolkit – but that’s fodder for another blog post.

PyCon 2017 Postmortem

The first half of this year has been full of travel for me – I’m hoping to post a data visualization of that at some point this year. In the meantime- I’d like to write a bit about PyCon.

PyCon (US) this year was in Portland, Oregon, home of Powell’s Bookstore, Voodoo Donuts, Salt & Straw Ice Cream, and Blue Star donuts. Of these, I would say that Salt & Straw and Powell’s were my favorite.

bookstore photo
Powell’s Bookstore

While my colleague and I were at the coffeshop inside Powell’s bookstore, we decided to take some time to catch up on work. I didn’t intend to break Python3 on my personal computer the day before tutorials started, but that’s basically how it went.

Kelsey Hightower’s brilliant closing keynote began with a recap of some of the rules about Python. One of them:

The first rule of Python: never mess with system Python

Of course, I had already broken that rule (rendering the GUI on my personal laptop unusable) the night before PyCon started.

Okay- now that embarrassing stories are over with, let’s get to the fun stuff. My main takeaways from the tutorials I went to were:

  1. There are matplotlib wizards in the world, and I would like to someday be one.
  2. I need to find an excuse to use Bayesian Machine Learning at work.
  3. I have a couple new reference points for how to test my code and my data.

I have to say that the testing BoF (Birds-of-a-feather) gathering was one of my favorite events. I enjoyed the conversation and the lightning talks, and it was a good way to unwind from a day of hard thinking.

Of the talks I went to, I probably most appreciated the ones that looked through Python C source code: several talks about the internals of Python’s GIL, and one on dictionaries. Other talks I went to looked through bytecode during the presentation. Both of these exercises I found incredible helpful, if only to provide a couple more tools for me to problem-solve and learn in Python.

If I’m still doing math and programming stuff for my day job in a year, I 100% would go to PyCon again.