...but this video gives a brief demonstration of the Ghetto Drum System that I built several years ago, and I just recently added MIDI over USB.
The sounds you hear are from a pretty sizable collection of samples ripped from (mostly commodity) synthesizers and played horribly by me in real time.
The Ghetto Drum is triggering MIDI into Pure Data (Pd) in order to play the samples, and the Dickhole Keypiss controller sitting on top of it is used to do bank programming and selection. Audio is routed out of the cheap-o netbook and into an even cheaper guitar amplifier.
So Paul hooked me up with a
Teensy++ with a couple bad pins a few months ago and I ended
up putting it to good use by retrofitting my Ghetto Drum system
in order to support MIDI over USB. The project page has been
updated and provides a few more details about the Frankenstein job.
I pulled open the old SyQuest case and unmounted the existing circuit board. After hacking at it
with the Dremel for some time, I was able to turn the board sideways to make room for the new
Teensy board. I mounted this new Teensy in the upper back and made a ghetto faceplate that allows the
mini USB connector to poke through.
I mounted the Teensy on a small piece of perfboard and made some super ghetto wooden standoffs.
I wired 10 pins from the Teensy over to the existing PIC board with wire-wrap wire:
2 power lines and the 8 trigger points. On the legacy side, I decided to solder the
connections right to the pins on the PIC chip itself. Whatever works!
This change allows the whole mess to be powered by USB when pluged in. The legacy PIC board maintains
its old function of reading the triggers and converting the data to RS232, but more importantly,
the PIC toggles the trigger LED whenever a pad is hit. :)
On the software side of things, I leveraged Dean Camera's LUFA
to build some firmware that allows the Ghetto Drum to show up as a USB MIDI device. When plugged in,
the device will show up with a clever name and show itself to the host computer as a USB audio/MIDI interface
device. When the triggers are hit, the Teensy sends note on/off MIDI events on channel 1 (zero based).
In order to make some sounds, I built a fairly involved Pd patch that
receives the MIDI events and can trigger drum samples from a gigantic library of synthesizers. I
used the Dickhole Keypiss with Pd
to program different patches and assign samples to trigger channels. After the integration was complete,
I ended up demonstrating the whole shebang one Monday night at Dorkbot in Portland.
I hope to have a demonstration video up within a few days.
I built this little midi controller to trigger samples and control a few Pd parameters:
It's based on an old touchtone telephone keypad, a rotary encoder, a two digit LED display, and a USB-based AVR breakout board (the Teensy++). The PC board was hand-etched at home, and it's mounted in a solid white, repurposed jewelry or makeup box, purchased at the Goodwill.
Click the above to view more images, read the brief technical spec, and to download the code and circuit/pcb design artifacts.
This is what the internet is really all about -- collaboration! A really generous German guy named Stefan fixed a deficiency (bug?!) in my NRPN abstractions. Thanks Stefan!
Previous versions wouldn't allow for controller numbers greater than 127...which is like half the point of even having NRPN (the other half being data values > 127). In any case, his modifications were somewhat simple and necessary and I incorporated them into and updated my pd abstractions page.
In order for me to confirm that the abstractions do what they claim, I used my BCR2000 control surface. I stumbled for quite some time with the nrpn_out.pd code, because the BCR200 was just absolutely refusing to recognize NRPN for a controller above 127. I hooked up a software midi dump (amidi -p hw:2,0 -d) to confirm that the bytes coming out of pd were as expected, and they were.
I feared that my controller was maybe shot or in a funky mode (everything else was working fine tho), and I tracked down a firmware update on the Behringer website. As is usual with this kind of firmware upgrade, it is a miserable Windows-only application, and I ended up resorting to using my wife's laptop to run it. Just once I'd like a manufacturer to properly support Linux...and if that's asking too much, just release the source and let people know how they can write their own. Trust me, given the code or at least a description of how to get the bytes into the device (protocol anyone!), the community will friggin build it for you!
Once the firmware was upgraded, the BCR2000 instantly started recognizing its incoming NRPN messages for controllers above 127. Goodie!
Thanks again for Stefan for helping out and contributing back to a community. It's exactly that kind of thing that helps make things better for us all.