THE MAGIC BEHIND
The basis is a programmable microcontroller with at least 8 analog inputs and a couple of piezo elements used as sensors. A piezo works like a close range microphone. If you hit it, it will generate some changing voltage. We need the microcontroller to pick up that voltage change, determine its characteristics and send MIDI messages to PC over USB. Then a music software in PC (DAW) can play various samples (drums, etc.) when those MIDI messages arrive. Arduino Micro was picked here because of its availability, relatively low price, size, and enough analog inputs to build a multi-sensor trigger.
HOW HITS ARE DETECTED
The microcontroller is periodically reading the values from its analog inputs (where the sensors are connected), one by one, to determine the current amplitude on each of them. We refer to a read value from an analog input as a "sample". Once the amplitude on an analog input reaches a certain value (the threshold), the program in the microcontroller starts to analyze upcoming samples. The input's maximum and the maximum of steepness - the amplitude difference between previous sample and current one - is recorded during a short period of time. Once the specified number of samples are read, it is determined whether it was an actual hit, based on the maximum amplitude and steepness, and the corresponding MIDI signal with the computed velocity is sent over to PC. To prevent erroneous re-trigger of the pad, the program at this point waits until the signal on the input goes below threshold again.
CHALLENGES
There were a couple of challenges to tackle during the development of hardware and software. The first was to find out whether the idea would work. A one-sensor setup was created first to record various hit styles, double hits, hand hits and drumstick hits. The recorded samples were then analyzed to find out how to detect a hit reliably.
Once the basic program was in place, and a two sensor setup was being tested, new problems arose.
The first was the slowness of reads. While a one-sensor setup worked like a charm, once the program started to read multiple analog inputs, read speed dropped dramatically. Based on various sources, the Arduino Micro has only one A/D circuitry, which is multiplexed to its analog inputs (a switch controls which analog input is connected to A/D). This switching seemed to consume more time than expected. Fortunately it was possible to solve the problem by setting the A/D converter for a less accurate, but quicker read.
Another problem arose from the single A/D feature. Inside, the A/D process works by switching the multiplexer to the input the program wants to read, then charging a little capacitor with the input, and after some time the capacitor is disconnected from the input and the charge in it is measured. Quick switching and reading of inputs seemed to cause that the capacitor had not enough time to discharge before next read, thus a hit on one pad triggered the others randomly. The solution to that was to connect an analog input to ground, and reading that input between every other input read, to short out the capacitor. In test build it worked, but when the board was fully assembled, the read of that grounded input seemed no longer necessary. Either the grounded pin is enough, or if all pins are connected to something, all analog reads are correct (and the theory about the capacitor not having time to discharge is wrong). Anyways, the pin connected to ground is left in the designs, just in case. You can use it as an extra input if you wish... (but tell me if it works without the grounded pin, please :) )
A WORD ABOUT CROSSTALK
The biggest challenge perhaps, was to eliminate crosstalk. The first crosstalk-like behavior was due to the shared A/D circuitry mentioned above. A bigger issue was a more interesting one. Once you hit something, the vibrations will propagate via the material the pads are installed to. Let it be a rod, or in this case, the whole construction of the bundled 6 pads. Like sound waves travel via air and water, it can travel via solid materials. To mitigate this, simple adhesive rubber pads were installed under each drumpad, to raise them above the back plate. Also the drumpads were cut to be smaller than the actual "holes" on the construction, so they don't get as much vibration from the sides.
This was of course not enough as a hit on a drumpad is enough to send the other drumpads flying. Not visible to naked eye, but the slow-mo videos revealed that this is happening.
Couple of thicker metal plates were installed (glued - i am not sure about its durability, so screwing could be a better alternative) under the backplate, to increase the construction weight, which is limiting its ability to resonate and to be as jumpy as it was.
The final countermeasure was to implement a simple algorithm to the hit detection: only those hits are considered a real hit, which are similarly hard than the most hard hit on the drumpad. Others are considered just crosstalks. This worked good enough for my taste, but has the drawback that you cannot hit one pad lightly and an other very hard at the same time - the former will be considered to be a crosstalk and not trigger MIDI event.
The crosstalk detection is applied only to the first 6 pads (the bundled ones to a single construction) and can be turned off entirely.
