Building an Audition List Database

Building an Audition List Database
Photo by Ylanite Koppens on Pexels.com

It can be daunting to decide what to build for my Flatiron School portfolio projects. It would be simple enough to gin up any number of meaningless associations for a database structure, but what I love about the power of the frameworks we have been learning is the promise of real-world practicality. The excitement of working through a project is the real working thing that you end up with. Coming up with a practical and useful concept can be the hardest step.

As I thought through the many web resources musicians use frequently, it struck me that there isn’t a commonly used collection of current and past audition lists. If you aren’t a musician, here’s the full run down.

The Audition Process

Whenever a position at an orchestra is open, that orchestra will announce the vacancy and post an audition date and excerpt list. These excerpts are selected specifically for each instrument and position, and are small snippets of music taken from the entire orchestral repertoire. The excerpt list can be anywhere from 5 to 50 individual pieces, sometimes with multiple excerpts from each piece.

Musicians who apply for these positions practice these small snippets for weeks and months to prepare for the audition. When the day comes to finally show off that hard work, a committee of current orchestra members will select a handful out of that extensive list, and the applicants will each take their turn (behind a screen to avoid undue bias). After each round, the committee votes on who will advance. Most national auditions have three separate rounds for an audition, sometimes culminating with a “trial week”, where the applicant plays with the orchestra during a full service week.

All of this to say the audition list and the excerpts on that list play a big role in any musician’s preparation for an audition. More than that, having a sense for what excerpts are called most frequently can guide the arduous process of preparing a particularly expansive list.

So… How do you keep track?

The current scope of resources online includes a variety of audition posting websites, such as Musical Chairs. These sites provide listings posted by orchestras big and small, in addition to non-performing job postings. However, there is no data about the excerpt lists on these sites, and a musician does not have access to any previous auditions for comparison.

Solution: the community needs an audition archive!

So Many Models!

To thoroughly provide search-ability for this project, I needed an extensive web of models.

  • User
  • Piece
    • Composer
  • Excerpt
  • List
  • Position
    • Instrument
  • Orchestra

The Anchor of the model structure would be the almighty List. Lists would be associated with a position and an orchestra, and through that position lists could be searched for by “instrument”. Lists would connect to the “music library” by having many excerpts, which belong to a piece.

The longer I spent on the model structure, the more I realized I would want each of these attributes to be its own model to facilitate simple searches, and also allow for methods to find the most frequently called excerpts for an instrument, or most common piece asked for by an orchestra. I also wanted to give users the ability to create their own collection of lists for easy comparison.

Thank Goodness for Rails Generators

With such a spiderweb of models, the rails model generator saved me countless hours when stubbing out the database. Still, implementing and checking these connections was time consuming. Once I finished setting up the associations, I set up all my CRUD (CReate, Update, Delete/Destroy) methods for each model.

This left the flow of the site in quite a mess, so I headed back to the drawing board to define the flow I wanted for my users. I ended up simplifying the flow to focus on rendering entries by instrument, and focusing the user on their own lists. The rest of the routes dropped into a route called “Library”, to allow curious users to explore and admin to edit.

The most satisfying part of the project was creating a custom stylesheet for my website. Simple but specific google searches brought me to some powerful css options, allowing me to create a clean and organized view that I hoped would represent this complex information without being too hard on the eyes.

Simple shadow boxes and a two column design made navigating my new database simple and intuitive.

I found myself at the limits of my programming ability when attempting to implement some kind of dynamic collection_select fields for excerpts. As the database grows, selecting the piece for a new excerpt from a drop-down menu would be very tedious, and I wanted to give the user a composer selection that would then dynamically populate the piece options. After some detailed searching, I found that the way to accomplish this was through Ajax and javascript, and none of the resources online provided a time-efficient implementation for someone who had no experience with this feature.

My goal for this project extends out beyond the Flatiron Portfolio. This app has serious utility for auditioning orchestral musicians, and my goal is to continue to streamline the project and someday make it live through this website. Musicians, stay tuned! For now, it’s on to the next module.