Videos:

1) Example Triplet Beat:

2) Device Functionality:

Glamour Shots:

Design Features:

• 9 pads; 60 percussion instruments available
• Assign pads to new instruments on-device
• Velocity sensitivity
• 9-note polyphony
• Reverb dial
• Console LED provides a visual signal that a drum has been hit.

Paper Prototype: See Mechatronics Lab (no photos)

• My last paper prototype included an overview of all the LCD screen prompts for instrument configuration. Prototyping forced me to look ahead to the coding process, because my minimal experience with C admittedly limited the number of feasible designs. I considered questions like:
• Q: Should the drum pads themselves be used as secondary buttons in the “SET” menu? Or, should there be additional scroll and “OKAY” buttons?
• A: It seemed the most intuitive design would adapt the drum pads as buttons in the “SET” menu. This way, users could simply click directly on the pad they wanted to change.
• Q: How many pins were available?
• A: I ended up using every pin on the Arduino Teensy, including the three inner pins, 22-24.
• Q; How can I best communicate on-screen information, given the space constraint on the graphical LCD?
• A: Ironically, this was the most difficult part of prototyping. Interfaces with ambiguous phrases (including some I’ve designed myself) can become dreadfully confusing, and so I was careful to avoid the wrong words.

Verplank Diagram:

State Diagram:

Final Code

Biggest Challenges:

• In chronological order: 

1)   Figuring out Real-Time MIDI on the VS1033D Decoder: 

• I spent a good amount of time researching MIDI protocol online, and then troubleshooting the order of command bytes to send to the decoder via SPI.  
• NOTE: There is an error in the VLSI documentation. In order to get the decoder to play MIDI notes, you must send 0xFF after each MIDI command and data byte. The manual suggests that you send 0xFF before each MIDI byte, but this does not work correctly. So, to be clear, send the data for each note in the following order:
• Command byte
• 0xFF
• Data byte 1
• 0xFF
• Data byte 2
• 0xFF

2)   Finding a sensor button for velocity sensitivity: 

o A bit of surfing around, with help from Megan, directed me to the Radioshack Piezo Transducer, which ended up working out perfectly. If anything, it’s too sensitive. The transducer reports values between 0 and 1023, which I mapped directly to drum volume. So long as the input exceeds some threshold (which ideally suits each Piezo, as they are not all created equal), I send a MIDI note-on message, at a velocity designated by the transducer.  

3)   Debouncing: 

o This challenge was two-fold. First off, I needed a way of preventing the drums from sputtering several notes off one finger tap. A simple delay would not suffice; this would keep the Arduino from listening to the other drums for the extent of the delay, and I wanted polyphony! The answer came in the millis() function, and the designation of a debouncePeriod array (one int for each drum; see code).  

o The next step in debouncing was finding the right material to act as a pad surface. I started with rubber, which had far too much bounce. I moved on to acrylic, which still failed to sufficiently dampen vibrations from finger taps. Hitting one drum made others go off. Ultimately, upon Jeremy’s suggestion, I tried foam, which had the right amount of give to it. 

o In this way, debouncing came down to nit-picky tweaking of variables like the pad material, surface area of the pad, and the surface area of the housing. 

Back-Up Plans:

• If progress on my drum pad suddenly came to a halt, I had two options:
• Build an MP3 player based on the Roman Room metaphor: users navigate a two-dimensional “music hall” on the graphical LCD to quickly access songs organized in quirky or unique ways. The “contents,” or songs, in each room can be organized corresponding to playlists, memories, people, genres, moods, etc. More importantly, the rooms are then organized spatially in the music hall, according to how the user views them to be related.
• Limit the functionality of the drum pad:
• I originally intended to allow users to set pads to melodic instruments, but this seemed tough to implement. For example, I would have had to:
• Include note-off commands
• Handle different MIDI channels
• Figure out the best default note duration
• Change the “SET” menu to allow users to configure melodic instrument pitches and channels
• Rework memory to fit a huge array of 128 instrument strings
• If necessary, I was also prepared to nix certain design features that, in the end, I somehow figured out. Such features included setting instruments on-device, implementing velocity sensitivity, and wiring up the LCD to show users the current pad assignments.

Lessons Learned:

• Draw up an electrical schematic before you take apart your breadboard circuit, and especially before you start soldering!
• Lessons in C: pointers, char arrays, efficiency, looping, etc.
• If you work really hard, you might get it right the third time…

If you build it, they will drum!