I’ve had a couple of people mail me asking about using raveloxmidi with rtpMIDI and I’ve put together a short demonstration to prove that it’s working with no complicated configuration required.
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.
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.
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:
- Get another MCP3008 ADC so that it can be used to clear an input once it’s been read.
- Wire up more than 1 drum input using more LM324 op-amps.
- 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.
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.
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 ( http://github.com/ravelox/pimidi.git ).
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 http://www.pjrc.com/tech/midi-drums/sch-ana1.html
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.
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 http://learn.adafruit.com/reading-a-analog-in-and-controlling-audio-volume-with-the-raspberry-pi/overview 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 https://projects.drogon.net/raspberry-pi/gpio-examples/tux-crossing/gpio-examples-1-a-single-led/ ) 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.
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: http://petervieth.com/projects/midi-drum-pad/ and http://leucos.lstilde.org/wp/2009/06/piezo-transducer-signal-conditioning/
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 (www.noisebridge.net) and they have sessions on a Monday which helps members learn about circuits’n’stuff so I may check them out.
Well, the original intention was to use pybonjour and dpkt but it got a little complex when I actually read through the RTP-MIDI RFC ( http://tools.ietf.org/html/rfc4695 ) and got to the section on journals.
I’m hoping that the reference code at http://www.cs.berkeley.edu/~lazzaro/rtpmidi/ will achieve what I need. I’ve looked it over and can see that there is specific handling of SIP packets.
SIP is used by standard implementations but Apple ( in their infinite wisdom ) uses their own protocol. So, I’ve written some C code to handle pack and unpack of buffers into data structures and vice-versa. This will be a replacement for the SIP code in the reference. My test code works with each buffer I’ve taken from packet captures. It unpacks into a data structure and I can then pack that data structure into a new buffer that matches what I read originally. A quick valgrind leak check shows that I’m not leaking memory 🙂
Now that I’m switching to C, I needed to look at avahi (http://avahi.org/ ) to register the service instead of pybonjour. There is a simple client example at http://avahi.org/download/doxygen/client-publish-service_8c-example.html which I will modify to my own requirements.
The sample uses a polling loop which never returns control to the calling program so I either have to run it in a thread ( which I don’t really want to do ) or to poll at regular intervals. Regular intervals works better because I also need to check the inbound UDP ports for RTP and AppleMIDI events. It also means that I can create a listening socket of some kind to receive input events from any other code I write to read the GPIO data from the interface.
Good job I have a few days off this week 🙂