Jump to content
davebranton

Midi drum pads

Recommended Posts

I decided to have a crack at building some drum pads, because the keyboard that I'd acquired for the kids to learn piano on had a midi input, and somewhat acceptable drum sounds to boot. After several months of sitting around half-completed under a cupboard, I decided to pull it out over the easter weekend and actually make it work.

 

In words, here's what I did.

 

  • Six drum pads, made of a square of hardboard with 5mm closed-cell foam glued to the top and standing on 15mm foam pads. Each pad has a piezo electric transducer underneath, attached using hot glue.
  • These six piezos are each hooked up to a buffer and biasing and clamping circuit, like below. The op-amp I used was an LMC648, which is great for this application but isn't that cheap.
    post-31167-0-12310300-1428265260_thumb.png
  • These six analog channels are connected to six of an MSP430's analog inputs. This micro samples these six inputs continuously, and uses a simple filter and threshold algorithm to determine when they've been hit.
  • Once it detects a hit, it outputs the pad ID (zero to five) and the 'velocity' of the hit over I2C to another MSP430.
  • This second micro in turn outputs the MIDI command, through a completely un-necassary additional chip to drive the MIDI output completely to spec. I know it's possible to output midi using 3.3v, but I used a driver chip anyway to run it at 5v - a TC4428 FET driver that I happened to have left over from another project.
  • The second micro also translated the pad ID to a MIDI note, and can be reprogrammed via a couple of buttons that are used to change the drum sound that's assigned to the most recently hit pad. The assignments are stored in the MSP430's "information memory" segment, so that it remembers how you set it up when you turn it off. I'd originally planned to put a 16x2 LCD on there, but I ended up using that for something else.

 

In pictures, here's what it looks like.

 

Overall:

post-31167-0-04542100-1428266193_thumb.jpg

PCB closeup - I would normally have a full eagle schematic and layout for this, even if I'm building it on stripboard, because I just make fewer mistakes that way. In this case though the layout of the six clamping circuits turned out to be much easier if I stood those components up out of the board (look on the right side of the picture) and wired them up over the top, and you can't really do that so easily in Eagle. 

post-31167-0-25366300-1428266221_thumb.jpg

Piezo closeup (under the pads)

post-31167-0-79551600-1428266240_thumb.jpg

 

And finally, in code, here's the two projects.

 

The ADC sampling micro : main.c

The MIDI outputting micro : main.c

 

Probably the most interesting aspect of this for me at least, was that when I was designing the (admittedly still rather crude) algorithm to determine how hard the pad had been hit, I needed to get the ADC samples off the chip so that I could experiment with algorithms offline and tweak their performance. I happen to have one of the rather wonderful saleae USB logic analysers (https://www.saleae.com/logic/), and so if you compile the ADC sampling micro's code with OUTPUT_SAMPLES defined, it will run the I2C at 1Mhz (instead of a much more reasonable 125kHz) and output all the ADC data as it receives it. This is pretty borderline for I2C, but if you keep the track length for the I2C nice and short you should be ok. In my case it's the orange and yellow wires in the PCB photo above - and of course you'll need both micros there because the I2C won't work if nothing's there to ACK.

 

Anyway, doing this I was able to get the samples back into my PC, and using python and pylot etc, plot handy graphs like this:

 

post-31167-0-69550200-1428267432_thumb.png

Python file, and two text files recorded from the inputs using I2C and the USB logic analyser : Archive.zip

 

The algorithm just detects when the input rises over some threshold, and while integrates the value before it crosses back over zero again (this is after the ADC samples have had 512 subtracted from them of course, making them signed). This is then considered the 'velocity', and the MIDI micro then divides that down to get a 7-bit velocity value for MIDI. This works 'ok', but very light hits aren't detected, and sometimes hits are quite a bit louder than you'd expect.

 

It's still fun though. 

Share this post


Link to post
Share on other sites

Lovely!

I have never approached debugging in the following way. I'm stealing this tip.

 

 

Probably the most interesting aspect of this for me at least, was that when I was designing the (admittedly still rather crude) algorithm to determine how hard the pad had been hit, I needed to get the ADC samples off the chip so that I could experiment with algorithms offline and tweak their performance. I happen to have one of the rather wonderful saleae USB logic analysers (https://www.saleae.com/logic/), and so if you compile the ADC sampling micro's code with OUTPUT_SAMPLES defined, it will run the I2C at 1Mhz (instead of a much more reasonable 125kHz) and output all the ADC data as it receives it. This is pretty borderline for I2C, but if you keep the track length for the I2C nice and short you should be ok. In my case it's the orange and yellow wires in the PCB photo above - and of course you'll need both micros there because the I2C won't work if nothing's there to ACK.

Share this post


Link to post
Share on other sites

I like to use a GPIO that I toggle in critical parts of code and monitor that with the Saleae alongside a comms protocol... very good when debugging actual comms peripheral driver timing issues :D (just did that with a USCI I2C driver a couple days ago)

 

Sent from my Galaxy Note II with Tapatalk 4

Share this post


Link to post
Share on other sites

I like to use a GPIO that I toggle in critical parts of code and monitor that with the Saleae alongside a comms protocol... very good when debugging actual comms peripheral driver timing issues :D (just did that with a USCI I2C driver a couple days ago)

 

Sent from my Galaxy Note II with Tapatalk 4

Hehe. I have used that before. Useful to see code execution timing. @@davebranton is dumping data out the I2C bus and plotting it out. Dumb me would have buffered it internally( hopefully enough ram ) and/or streamed it out via  a serial port into a csv file.

Share this post


Link to post
Share on other sites

Hehe. I have used that before. Useful to see code execution timing. @@davebranton is dumping data out the I2C bus and plotting it out. Dumb me would have buffered it internally( hopefully enough ram ) and/or streamed it out via a serial port into a csv file.

Yep- my favorite for that is SPI, since it's superfast :D

 

Sent from my Galaxy Note II with Tapatalk 4

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...