Sample Rate
-----------

The number of samples taken since the last HID report
is sent as the second Y axis.
If you use the 
[included gamepad tester](gamepad.html),
it will show the approximate number of samples as an integer,
for Y axis 2.

This is approximate,
because the browser encodes the value as a real number between -1 and 1.
We convert it back, but may lose a little precision.
It's close enough for me,
hopefully it's close enough for you.


Debouncing
----------

Using `millis()` time to debounce the switch
roughly halved my sample frequency.
So instead, I do some preprocessor arithmetic
to calculate how many samples to take after an edge,
in order to debounce switches.

The drum controller was a partcular pain:
in addition to the switch bouncing,
the stick was bouncing on the rubber pad.
I settled on a 40ms silence window as feeling pretty good.
You can adjust this if you want to.



USB Junk
========

Gamepad Buttons
---------------

The `buttons` struct member is a bitmap,
each bit mapping to one of the 12 buttons reported through HID.
Here's what each bit means:

* 0o00: Blue
* 0o01: Green
* 0o02: Red
* 0o03: Yellow
* 0o04: Orange
* 0o05: Tilt Switch / 2x kick
* 0o06: Solo modifier (second row of buttons on guitar)
* 0o07: ???
* 0o10: Minus
* 0o11: Plus
* 0o12: Drum pad modifier
* 0o13: Cymbal modifier
* 0o14: Select


hatAndConstant
--------------

Here's what the values mean:

* 2: right
* 6: left
* 0: up
* 4: down
* 8: nothing


velocity
--------

I don't know how I can verify that I'm setting this right,
but the `rbdrum2midi` program looks at these bytes to detect hits.
I set them to 127 when a hit is detected on the digital pin.

Sending these values does not seem to cause problems with my Wii games.