HandyChord

Associations vs Literal String Names

Hello World!

To be honest I don’t think I’ve ever made a “Hello World” program.  I kinda skipped right past all the basic stuff and took a much larger bite than I could chew.  And I’ve been chewing on this same piece of MVC framework for about 5 months now.  It tastes pretty good though, so I have no complaints.

Today was going to be the day that I started recording dozens of chord videos for HandyChord.  A very tedious and mind-numbing task, that has to be done.  I’ve been procrastinating by taking care of each and every other task of considerable importance first.  This weekend I ran out of tasks, but today, a new one jumped right up and saved me.  I’m not creating work for myself either, this is important.

As I was working on my chord list, I realized that my then current system for providing multiple names for the same chord was wildly inefficient.  I had created it, perhaps, on day 5 of development, and it was as simple as it can get.  After adding a new chord to the database and uploading the video file, I simply entered into a form all possible alternate names for the chord that I could think of.  So if I had just entered C Major, I would type CM [enter] CMa [enter] Cmaj [enter]C ma [enter] Cmajor…. etc.  You can see how tedious that can be.  As I was calculating the THOUSANDS of chord videos that I will eventually record, I started doing the math.  I would be entering TENS of thousands of alternate names.  (This is important, by the way, for searching purposes.  There are dozens of “correct” syntaxes for chord naming.)  I didn’t want to admit it, but this was a huge oversight on my part and no matter how much I tried to tell myself that I could keep doing it that way, I couldn’t deny that it would severely slow down my progress, and increase my chances of getting carpal tunnel from all that typing.  So I was forced to delay my recordings again, and work on code.

I decided to toss out the list of literal names, and go with a 3 tiered association.  I have chords, that have a quality.  That quality in turn, has “Alternate Qualities”.  So, Chord->Quality->AlternateQuality.  Pretty simple right?  Wrong.  The Qualities and Alternate Qualities do not have any chord roots stored in them, because ultimately, many chords will share them.  C major can have “major”, just like D major can.  And if they both have “major”, then they both have every alternate quality that “major” has.  So, how does this help me with my search problem?  It’s easy enough to match a literal name with a search query.  Someone might want Dbm.  That query can easily fetch Dbm, Dbmin, Dbminor, and so forth.  How do I match a search query with something in the database that does not have a root assigned to it?  Clever code.

I am currently working on a series of nested if, else, and elseif statements that tackle every typical way to write a chord symbol, and analyze the content to decide what the user’s intended root and quality was.  So if someone enters “D sharp Dimin”, my function will be able to convert that into a D# root and a Diminished quality, and return all the chords that fit that criteria.  I can’t predict every way that someone could request a chord, but I think I can foresee the typical ones.  This way I can save my fingers and a lot of time!

If you’ve read this entire post, I am impressed.  Thank you.


  1. funcyeahcompsci reblogged this from handychord and added:
    A programmer tackles the natural language to database entry problem of chord abbreviations. There’s several correct ways...
  2. handychord posted this
To Tumblr, Love PixelUnion