Building a MIDI Controller

This is a project that has been a long time in the making. If you go back to the earlier posts of this blog, you’ll see how I started with my first Raspberry Pi back in 2014 and my intention to use it as an interface with a electronic drum kit.

Since then, I’ve developed raveloxmidi as the proxy from a Raspberry Pi but I never worked on the hardware. I’ve had other people use raveloxmidi and they seemed to be please with it.

Last month, I saw a video from Angus at Maker’s Muse ( who build a controller using arcade buttons and an Arduino.  I remembered that I had a set of arcade buttons that I’d bought from eBay.

This seemed like the perfect opportunity to put my money where my mouth was and build my own controller. Here’s the video of how I did it:

I’m going to write up my thoughts on the quality of the video. You’ll see a counter incrementing each time I say the word “SO” in my commentary. It bugs the heck out of me and it’s something I need to improve on but it’s a little fun seeing how many times I say it.

Darn it all to heck!

At some point between making the triumphant ( now seen as premature ) video of the input circuit working and now, the little elves of mischief have removed a vital but undiscoverable piece of the circuit that is preventing it from working.

It’s a little frustrating as I’ve taken it all apart and rebuilt it plus I’ve replaced the op-amp in case I blew the chip ( not that likely ).

So, in the absence of inspiration or serendipity, I’ve replaced it with another design from a previous post. It Kinda Works(tm) but I’m back to having a trailing voltage when then I read the ADC which means a double reading. I’ve connected up the multiplexer to drain the capacitor but it’s not draining that quickly.

So, into the box it goes and I’ll take a short break to concentrate on something else.

A little redesign

I realized that I didn’t need another ADC to clear down the capacitor. The circuit I’m basing this on uses 2 multiplexers: 1 for the input select to send on to an ADC and one to clear the capacitor for the selected drum input. The design makes sense because you’re selecting the input and those same input selections will also be used to select the clear down.

However, given that the MCP3008 (ADC) has 8 inputs, the first multiplexer is redundant.

So, I now have the ADC and one multiplexer.

I put together a test circuit to make sure that I understood how to talk to the multiplexer and that seems to be working fine.

It all works !

After giving up for a couple of days because it wasn’t doing what I wanted, I took everything apart and rewired it. This time, it functioned as I wanted it to!

There are more things that I need to do:

  1. Get another MCP3008 ADC so that it can be used to clear an input once it’s been read.
  2. Wire up more than 1 drum input using more LM324 op-amps.
  3. Rewrite the python code in C so that latency can be as low as it can be. I may attach the Raspberry Pi to a network hub/switch so that WiFi isn’t part of the equation.

Multiplexer vs ADC

As I’ve been preparing to build a test circuit using the CD4051 multiplexer, I’ve realized that a multiplexer isn’t an ADC. The CD4051 is an 8:1 multiplexer meaning that the Raspberry Pi will select which of the 8 inputs to select to read from the 1 output. That’s fine and dandy if all I want to do is to check whether a drum pad has been hit. It’s a 1 or a 0 for on off.

However, if I want to determine velocity ( how hard the pad has been hit ), I need to be able to measure voltage too. This is why I need the ADC.

I still have the MCP3008 ADC chip from my previous circuitry. So, what I’m planning to do is to connect the output from the CD4051 to one of the inputs on the MCP3008, select the CD4051 input using 3 GPIO pins and then permanently select the single input on the MCP3008 and measure the voltage.

At least, that’s the theory. First step is to get the Raspberry Pi talking to the CD4051 in the first place. I’ve laid the groundwork down by making sure I understand exactly which GPIO pins to assign to be the A/B/ C input select on the CD4051. Next, I’ll build up the circuit for the drum input using the LM324 op-amp.


Like a phoenix from the flames….

It’s been a (very long) while since I did anything with this.

I’ve been focussing on the code to get a MIDI event from my binary to Logic Pro X and I took a long break between iterations 🙂

However, I have succeeded. I’ve put the code on GitHub ( ).

The next step is to build a circuit again. I’ve found a different approach that will mean I don’t need to guess when the drums are hit. Information is at

What’s the (decimal) point ?

So guess who read the capacitance incorrectly ?

4.7uF is *not* the same as 4.7nF. Like I suspected, I’m using a capacitor that’s too big for the job. So, I’ve ordered some nano-Farad capacitors.

I played around with replacing the 1M ohm resistor with a variable potentiometer and that allows me to “tune” the signal a little more so that I can make the circuit more or less sensitive.

I think I also need to change the algorithm that’s sampling the data because it has some problems where it’s still measuring the decay (which should go away once the right capacitor is in place) but it’s also displaying the same measurement in a short period of time (milliseconds ?).

I did have it so that the measurement is only done when the delta between the current reading and the last one was positive ( an increase ) but that doesn’t allow for when I go from a hard hit (high number) to a light tap ( low number ). I figure that if the capacitor was smaller, the voltage will be held for a shorter amount of time and will drop to zero quicker meaning that sampling a positive delta will always be an intended event. TIme will tell. I’m just waiting for the postman now.

It's Alive !

It’s Alive !

The Circuit

I actually got the circuit wired up again and, somehow, it seemed to work this time. I saw a voltage change with small taps and large hits so the next step was to connect the ADC (MCP3008) and the Pi Cobbler (GPIO cable connector).

So, I consulted the project at and wired up the GPIO pins to the ADC per their instructions.

I also took the python script from the same project and hacked it to remove the audio volume stuff.

It was during my initial test that I found I had connected the GPIO cable the wrong way round on the Pi which meant that nothing worked. My first thought was that I’d broken something but I pulled everything out and did a quick LED test ( see ) which proved that none of the GPIO pins were responding as they should have done. So, I took the case apart, turned the cable around and reassembled everything. This time, the LED test worked as I expected (cue a quick Gangnam across the living room to celebrate ).

After wiring the ADC up again, it was a success as this video shows:


Next to do is to remove the capcitor to see if I can get the slope to decay much quicker.

Information burst

More reading, more changes of mind.

As my requirements for this MIDI interface are limited only to sending notes, I came to the realisation that I don’t need to handle journals inbound to me and the only journal I need to create outbound is a Chapter N for NOTE ON/OFF events. After playing with reference implementation and copying most of the sample code from the RFC, I’ve taken it all out again and I’m starting from scratch. The RFC code isn’t the best example of a Chapter N journal so I need to go over the details again and translate the concept. I’m sure it’s relatively simple, I just need to wrap my head around it (I’m a bear of little brain).

I have 2 binaries right now. The first is a simple Avahi registration app that publishes host and port 5004 and the name of the service (_apple-midi._udp). The second listens on the ports for events. The listener app is correctly unpacking the Apple MIDI events. I did clean up some segfaults when the OS X MIDI app ends the session ( by sending a BY event ). I’m debating whether I want to handle just 1 session or multiple.

On the hardware side, having got a little bored of starting at C code, I spent some money at Radio Shack and other places to get capacitors, resistors, diodes and also some 3.5mm audio inputs that are breadboard combatible.

I did some reading up on how to handle the drum pad inputs. As the teardown showed, it’s a piezo trigger and, according to the internet, that requires some special handling.

The following pages are useful information: and

They show the circuits needed to handle a piezo input.

Here’s my problem right now. I built the circuit using the info from Peter Vieth’s page and, if I connect up my multimeter, I can see there is a change in voltage when I hit a pad but it’s very small. Some of the many questions I have is whether I’m supposed to be seeing such a small voltage change ( which I saw when I first tested the pad a couple of months ago ). In some cases, with light hits, I don’t see a change at all.

I connected the drum pads back up to the controller they came with and they play fine. Light hits are registering so I know I haven’t broken anything ( hard to do seeing as it’s a piezo trigger ). The controller uses a 9v DC input and I’ve hooked my circuit to a 9v battery but see little change.

The other question I have is whether I’m actually using my multimeter correctly or if I should even be seeing anything register with a multimeter. The info on the Leucos site shows some good data using an oscilloscope but I don’t want to get into that at my stage of life ( $$$ ).


I guess more reading is in order. I have some work colleagues that are part of Noisebridge ( and they have sessions on a Monday  which helps members learn about circuits’n’stuff so I may check them out.