Naturally, I want this thing to be sitting on my desk, ready to crank out a beat at all times. And naturally, the computer that's sitting on said desk is not running Windows. The great thing about this present is that it's given me a cool new side project to work on.
The first thing I did was determine that it is a pretty standard HID. It chucks out 8 identical bytes in its report. Looking at one byte, the 6 low-order bits each represent one pad on the drum kit, with a 1 indicating that the pad is being pressed.
My simple test program pipes
stdinand reads it to
bufin a loop. The following logic compares the current state to the previous state, and if a new pad is being pressed, it sets
padto the integer value from the image above:
dtot = buf[ 0 ];
raw = ( dtot ^ dtol ) & dtot;
dtol = dtot;
pad = 0;
while( raw )
raw >>= 1;
Just to see it in action, I added a fork and
execlcall to the loop that plays a different wave file for each pad through aplay. Among other things, this is a poor solution because fast drumming or long wave files will quickly fill up the available channels on the sound card, so that sometimes the sounds don't play at all.
The next step is to get this working with libhid. I ran
lsusb -d 1941:8021 -vvvto get the details about the input and output paths, but I haven't had any success getting an input report thus far (apparently, I'm reading the path wrong somehow, will ask the libhid mailing list).
Once input is coming in properly, I'm planning to look into a better way to play the sounds (pre-mixed, so that only one hardware channel is needed), and I may also write a simple GUI that lets you assign samples to each pad easily.