Snare Drum Notator




Sponsors	Spencer Martin
Team Name	MusIQ
Duration	Fall 2016 - Spring 2017
Faculty Advisors	Dr. Greg Donohoe
Students	Scott Dennis Nathan Groggett Phil Kearns Hue Purkett Domn Werner

The goal of this project is to simplify the process of generating sheet music from played music. It is normally a complex and time intensive process that often interferes with creativity. This snare drum notator will simplify the process by recording the drum strokes and directly creating sheet music from the recording. This can also be an aid to those who are learning how to play the snare drum. As it allows quick feedback.

Problem Definition

Specifications

Goals	Requirements
Recording	Record any rhythm that a drummer has played.
Display	Take the rhythm played and convert it live, into sheet music.
User Input	Allow the user to input both the time signature and the tempo of the played piece. In addition device should be able to take user input to start and stop recording, and potentially change time signature in middle of the piece.
Accuracy	The music displayed on screen needs to be accurate to what the drummer played. In addition it needs to be displayed quickly so the drummer can see exactly what Rhythms are played.

Sheet Music Style

The sheet music will be stored through the file format of Music XML. This format has become a popular standard in recent years, and is compatible with popular music editing software (ex: Sibelius and Finale).

The following elements are common in snare drum music and will be supported by our team:

Volume/dynamics
Sticking(left, right, or both hands)
Position on the pad
Back of the stick vs front of the stick
Rudiments(rolls, flams, rimshots, ...)
Accents (louder hits) vs taps (softer hits) relatie to current volume
Tempo
Whether the user is hitting the rim or the pad
Dynamics (increasing/decreasing volume)
Time signature
Rests

Design Concepts

When brainstorming ideas for how to build a Snare Drum Notator the following criteria were considered of the hardware.

Hit detection is the ability to detect a drum stroke.
Durability is how long the item in question would last with prolonged use.
Precision is how accurate, and consistent the data would be gathered.
Information parsing is how easily the information gathered can be translated into sheet music.
Quick User Input is how easily the user can control the software. such as starting, stopping, and setting the tempo.

	Microphone	Pressure pad	Sensor on Pad	Gyroscope on arms
Hit Detection	A microphone can effectively detect both the hit and its intensity but would be unable to detect which arm played the note without additional microphones and data input.	A pressure pad would be be able to detect the hit, the location of each hit, and its intensity. The location of the hit does not guarantee knowledge of which arm played the note.	A sensor on the pad would be able to detect the hit but without more data it would be difficult to tell which arm the note was played.	Gyroscopes on the arm would be able to detect each hit, the intensity of the hit, and which arm played the note.
Durability	There is no direct wear on the microphone other then the detection of the notes. Likely not significant wear. Only general expected lifetime of the device would be a concern.	The pressure pad would deteriorate quickly on any area heavily played on.	Sensor on the pad records information using a 9 degrees of freedom block. Because it would absorb the vibrations from the pad and not the stick itself the only wear that would be problematic would be the general lifetime of the sensor.	Sensors on the hand record hit detection by movement of the arms. This causes only general lifetime of the electronics to be a concern.
Precision	Though precise in a silent room there is a chance the microphone would pick up residual noise as a drum note.	Though precise in the beginning as the preassure pad wears out precision would decrease.	The sensor on the pad would pick up consistent information as long as it wasn't moved from a set position.	Due to its measurement of the arms movement for hit detection, the gyroscopes on the arms would be most precise at picking up data. Though dependent on how they are secured to the arms.
Information Parsing	Information recorded from a microphone may be difficult to parse, especially from a analog to a digital value.	Most pressure pads already have libraries for getting the data so should be easy to parse.	The sensor on the pad would output large amounts of data though it would be very clear as to what that data would be and represent.	The gyroscopes on the arms would be as clear as the sensor on the pad though twice the amount of data because information would be coming in from both arms.
Quick user Input	Might be able to use voice commands with a microphone but that requires word recognition software.	The pressure pad would have no direct way of user to input a stop sequence without potentially interfering with detecting hits. Though extra hardware could be added.	A sensor on the pad would also have the problem of having no direct way of getting other user input. However extra hardware could be added.	The gyroscopes have the potential of getting user input by gesture detection. Because a gesture would be likely be more evident then a simple drum stroke.

Based on the above criteria, gyroscopes on both arms would be the most optimal approach. The gyroscopes are able to meet the expectations of every category above while at the same time grant the potential of extra user input without excess hardware. In particular the ability to detect left and right drum strokes easily was especially appealing.

Bluetooth

In order to enable hands free drumming the Bluetooth module on the Intel Edison will be utilized. This will allow 2 Intel Edisons to communicate with the main application on the Computer. This is further enabled by linking them to an external Bluetooth dongle so that any computer running the main application will just need that dongle and everything should function as expected.

In order to get the Bluetooth working on the Intel Edison, information was utilized from the following source: https://people.csail.mit.edu/albert/bluez-intro/index.html

In addition for the application the 32Feet library is utilized to enable Bluetooth hanshaking in the C# language. Here is a link to their web page: http://32feet.codeplex.com/

Music XML

Music XML is a library made by makermusic. This library has extensive documentation and detailed representation of drum music. In addition They support an incredible large amount of notation to allow for accurate music representaion.

One of the largest benefits of Music XML is its ability to be read by many music editing software. Including but not limited too:

Encore
Finale
Musescore

For more information about Music XML supported library's visit: http://www.musicxml.com/software/

Experiment

Basic Drumming Tests

Below is the initial gathering of data. This data will be used as a guide to create the actual note parsing. As you can see on the far left side is what music was played on the snare drum. While the next two columns are the Left and Right hand respectively.

Sheet Music	Graph of Left Hand	Graph of Right Hand
sixteenths then buzz strokes
Eighths then Doubles
HeroLickMusic
Quarter Notes

Bluetooth Druming Test

Team Information

Picture	Bio	Discipline
	Scott Dennis: I am a Moscow local who began studying at the University of Idaho after graduating from Moscow Senior High School. I began working towards a degree in Computer Science and immediately fell in love with the discipline. Needless to say, I have continued studying it since. I am currently in my fourth year, anticipating graduation in May 2017.	Computer Science
	Nathan Groggett: Originally a student of Northwest Nazerene University, I encountered program at the end of my Freshman year and fell in love with coding. So that I wouldn't have to give up Electrical Engineering I transferred to the University of Idaho the following semester and enrolled in the Computer Engineering Program. I have always had a passion for building things from the ground up and whats more ground zero then the circuit board and the code to run it. I am anxiously awaiting the end of my fourth year, to see where life will bring me after graduation.	Computer Engineer
	Philip Kearns: I am currently a senior double-major in electrical engineering and physics, and was born and raised in Portland, OR. I came to the University of Idaho uncertain of which branch of engineering I would major in, but the professors in the EE department won me over. Over the past three years, I’ve developed a passion for wearable technology and data analytics, something I’ve had the chance to explore over two summer internships at Intel. After (hopefully) graduating in May, I plan to pursue a M.S. degree in electrical engineering, with a focus on machine learning and pattern recognition. When I’m not sitting in class or lab, chances are high that I’m sitting on my bike.	Electrical Engineering, Physics
	Hue Purkett: Born and raised in Port Orchard, WA, I came to Computer Science just two years ago after thoroughly enjoying a CS course taken on a whim. I expect to graduate in May and go on to work somewhere as a programmer.	Computer Science
	Domn Werner: Originally from Brazil, I moved to the United States at age ten. By my senior year of high school, I had become captivated by computers and decided to pursue a degree in computer science. Now at my last year of my B.S. in computer science, I have garnered great passion for software engineering and cybersecurity. I apply and improve both disciplines at work as a cybersecurity/network specialist, at school by taking advanced security classes, and at home with personal projects and entrepreneurship. I look forward to the advances in cybersecurity, quantum computing, and software engineering as I pursue my M.S. and Ph.D. in computer science.	Computer Science