The definitive MIDI controller

What is RPC?

The Raspberry Pi Controller is intended to be a stand-alone MIDI sequencer workstation, made with open-source software and DIY electronic components. It is built around a Raspberry Pi board delivering a solid user interface. The I/O connections are served by an Arduino feeding directly to four MIDI inputs and outputs, guaranteeing accurate timing.

The name pays homage to the venerable Akai MPC series, but this is going to be a whole new kind of beast.

If this project is of interest to you, or if you would be interested in having your own little RPC (DIY, kit or pre-built, doesn’t matter) please drop me an email, tell me what you want to see me accomplish, and I will add you to the news email list. You’ll be the first to hear of updates, and I will be aware if someone actually wants one! No spam.

The protosynth

The DSP synthesizer project has taken most of my attention lately, with the RPC making steady progress on the background. The unique synthesis algorithms of the synth will make it a beast of a companion for the RPC.

Recent posts

It’s alive!

The box for the protosynth is finally complete. See the previous posts for details. The paint is still not entirely finished and could use some final touch-up, but it’s good enough for now. First pics!

Sumutor-1 ready to rok

Sumutor-1 ready to rok

All the hardware is in there and, most importantly, it all seems to work. All knobs and buttons register, leds light, and although there is no real gui, you can tap on the mock buttons and they register. Headphone output works, but I’m not sure yet if the voltage levels are right or if it’s clipping. All the parts of the synth work just as before.

The picture is taken at such an angle that the display looks empty. No, it works just fine. The led segment displays will get covered later, I still have to find some nice red film to put on top of them.

Sumutor-1 with its fleshy belly open

Sumutor-1 with its fleshy belly open

All the internals are in place. In the cover: thumbstick, big buttons and the headphone amplifier on the left, with the main UI panel and the touch TFT screen with its SD card slot taking the rest of the space. On the bottom: the synth on the left has grown itself an opamp attachment and a couple of admittedly ugly connectors, the USB+MIDI interface in the middle, and power supply board and the power connector and switch on the right. Oops, I forgot to remove the jtag cables for the photo shoot.

I’ll take some fancier shots and soundclips later (see the previous posts though!). There’s still much to do on the software side.

Audio analyzer enclosure design

This was where I really started the project. It’s also the most fun part. :-)

The front panel: what you see is what you interact with

The first sketch of the front panel already gave a good idea of what I had thought the analyzer should do.

THD analyzer front panel, first sketch

The audio XLR and TRS connectors for plugging in the device-under-test would be on the front-left, since those need to be easily accessible. There also has to be an “auto” button to measure everything in one go. (What exactly should that do, you ask? Details… to be decided later on. ;-)

The box will get an IP address, so some menus are for sure necessary to at least read the status and perhaps configure the Ethernet link. One button for that.

Most of the controls will be for the signal generator, as it will be hugely convenient to be able to dial in a specific setting and then debug the device receiving the signal. The analyzer is synchronized with the generator and is therefore quite automatic. The signal generator’s output is most likely going to be just a sine wave, so level and a frequency controls are in order, and sufficient. A frequency dial alone can be inconvenient for scrolling a long way, so two buttons next to it for going up and down whole octaves at a time will make it more accessible.

The signal generator’s output level setting should be straight-forward: decibels relative to some reference level. It just happens that there are a few different ways to define the reference level. There are at least two different yet common scales used for defining signal levels, the dBu standard and the dBV standard. dBu is used in “professional” gear, where signal levels are overall hotter to make use of the extra dynamic range afforded by it, and also because such devices have higher voltage power rails and therefore more headroom to work with. dBV on the other hand is used for cheaper devices that may even be battery-powered. The whole business of such reference level smells a bit old-fashioned, but since these are still commonly used, it should be possible to switch between them. I also found a handy web tool for converting signel levels from one scale to another.

It could also be very handy to be able to set a different custom level as the reference and measure everything relative to that; even better if you could use the current input level as measured by the analyzer as the reference, and it should only take a single button press to do it. Some way to quickly skip through common preset levels is also needed, for the same reasons as the frequency control needs buttons, and that gives the third button for the level controls.

On the right-hand of the panel is a rocker power switch on the bottom, and a wide-levered output enable switch in the same style as on the constant current loads I built earlier (and now I realized that I forgot to write a post about those.)

At this point I still had an empty spot on the panel, and could only think of spending the space for two less critical switches: a balanced/unbalanced I/O button and a bandwidth limit control. The idea with the bandwidth limit switch was to force the analyzer to use the lower 48 kHz sampling rate, with higher dynamic range and improved THD. To measure the distortion of >5 kHz signals it would still be necessary to enable the 96 kHz or 192 kHz sampling rates, but it could be useful to disable such automatic reconfigurations.

The balanced/unbalanced switch takes care of the level adjustments needed with the two different interconnects: simply grounding or muting one side of a balanced cable would reduce the signal level by half, causing a significant measurement error! This can be automatically compensated for by switching the analyzer to unbalanced mode.

At this stage I was sure enough of the practicality of the project, that I designed the PCBs and ordered and built them. I will write more about those in later posts. After verifying the general concept in hardware, it was time to decide on the final design.

Making it tangible

Again I went for Protocase to manufacture the enclosure, just because of the simplicity of their own cad design tool and the handy templates. With a little bit of good advice from Sebastian (check out his site for some really cool art!) I hacked together a more realistic design. The most important tip I got from Sebastian was: keep it simple. Even very simplified designs look awesome when they’re made into tangible objects. Typography should be simple but elegant (heh, maybe that’s still not my cup of tea) and emphasis should be on legibility and usability. So I kept it minimal.

THD analyzer 3D model

Colors are hard; somehow I have no intuition of which colors or tones work well together, but I knew the LCD screen would be blue, and inverse colors often work well together. But should it be orange, or should it be yellow, light or dark, saturated or not… choices, choices!

This is also where the projects gets expensive – it’s much cheaper to make your own boxes out of wood or plexiglas, but these enclosures are really high quality and have a seriously professional feel! Even better, they’re very low-effort if your wallet can take the hit.

But when the postman arrives, it’s like Christmas all over again ;-)

Analyzer delivery!

That is definitely not the end of the process, but since you read it all the way here, have a treat. I really like it how the whole design turned out!

Final THD analyzer

I think I spent weeks just selecting the right components for the front panel. Connectors were easy, I’m used to Neutrik jacks. Likewise the LCD display is a common part, it pays off to keep a good supply of those, and the prices are very acceptable when buying in bulk.

I must have pored over tens of shops just looking for knobs. It was so difficult to find good ones that we even considered making our own molds with Stijn. I don’t think I’m quite ready for that yet, but it would definitely be an option for larger production runs. Those that I used on the Protosynth I found first at Conrad, and later in different sizes at Das Musikding. The bigger sizes felt just right for this project. I covered them thoroughly with Plasti Dip, also to improve the plasticy feel of the plain knobs. The rubber paint gives them a very nice grip. The encoders are not both the same; I envisioned that the level knob would also be used to make a selection in the menus, so it should have a good stepped feel. After trying a bunch of different ones, I decided to go for Alps. The frequency dial is a smooth encoder from TT Electronics, and it requires medium force to turn, so that precise frequency adjustment is easy.

The buttons are Marquardt 6450-series from Mouser. I think Clavia also uses them in their synthesizers. The leds next to them are just 0603 SMD leds placed directly on the PCB behind the front panel, but I found out that Toby has a good selection of light pipes in practical sizes, and got a bunch of those. The light pipes carry the light so that it looks like the light is emitted from them, and they are also flush with the panel. This way the front panel PCB can be inserted in place very quickly without having to worry about the placement or spacers of the LEDs. The light pipes are short enough to stay in place by just pushing them through the panel.

On the back of the enclosure there’s just an Ethernet jack, USB jack (I still don’t know what to use it for – USB audio? In mono? Not very useful…) and a power jack. I also added a MIDI jack but it’s also an option for later use.

Inside the THD analyzer enclosure

The insides of the enclosure are spiked with standoffs for attaching the PCBs. Sadly here Protocase made a small mistake and left out two standoffs on the front panel. I had to replace them with screws and spacers. Pity for the screws are now visible on the outside… I also still have to find some black self tapping screws for the XLR connectors.

The rubber feet keep the box steady on the desk when buttons are pressed, and even when the small but sturdy power switch is operated. The box is made of just two parts, the base and the cover, and the base is very thick and heavy; it’s 2.3 mm thick steel! The box is too heavy to lug around, but it feels very robust and reliable, which is definitely a plus.

Digital design for embedded DSP

Interfacing with a DAC and an ADC is not too exciting, but to make a complete device some other “small” features are necessary. The analyzer will need some serious DSP power to run reliably at 192 kHz and to calculate the long FFT needed for the spectrum analysis, and at the same time it would be nice to have sufficient connectivity for remote control of the system. It would be especially nice to be able to download the recorded and/or processed data, and to use the analyzer device as a high-quality but mono audio interface.

I’ve had good experience with the LPC series of microcontrollers, and the NXP LPC43xx was the obvious candidate for this purpose. It’s a dual-core design, with one ARM Cortex-M4F core with hardware 32-bit floating point support, and the other core is a Cortex-M0 that still runs at the same maximum clock frequency of 204 MHz. That’s a lot of MIPS/FLOPS to burn! The M4F could do the signal processing and interfacing with codecs, and the M0 core would take care of everything else.

THD analyzer logic

I really like Ethernet and TCP/IP as an ubiquitous way to connect computers, and the LPC4333 has a built-in Ethernet MAC. It requires an external PHY (Ethernet line transceiver IC), and the PHYs seem to be only available in tiny QFN packages that take some skill to solder. Gotta learn that sometime, so why not now. The Microchip LAN8720A is again an obvious choice.

This application is going to need a lot of memory, much more than is available on the LPC MCU. The LPC4333 has a memory controller, and it should be easy to connect some SDRAM to it. The memory will be accessible by both cores, so the DSP core can write to it and the controller core can read the contents and send to the remote controller over Ethernet. Is the memory bus fast enough for that, and does the sharing between the two cores cause problems? We’ll have to see… The memory bus on this particular CPU is 16 bits wide, and a 192 kHz 32-bit audio stream will require about 1.5 MB/s of bandwidth to transfer to memory and back. Probably I will want to store more than that at the same time, but in any case the bandwidth of even just a 100 MHz (half the CPU clock frequency) 16-bit memory bus should be way more than sufficient. SDRAM requires some overhead for setting up the transfers and for refreshing the memory, but there should be so much extra headroom on the bus, that this should not be a problem at all.

The device should be capable of standalone operation (and I like having dedicated physical controls) so a frontpanel is a must. The 16 character, two row LCD display is a little bit small, but it’s easy to read and easy to program. After making some sketches of the data to be shown on the display it was clear that it could still work for this purpose. The most economical approach (in terms of saving design time) would be to use a dedicated MCU for the front panel controls, and drive the LCD directly from the main CPU.

USB and MIDI ports could be added too, the LPC is very flexible. But this application doesn’t really need those.

But look at the picture above! Even though the THD analyzer device is relying heavily on its DSP and analog performance, these parts appear as a very small part of the overall system. This seems to be a common theme in devices intended for hands-on use. Interfacing with external systems, and especially with humans, is quite expensive.

The plan, analog hardware design

Having discussed the purpose and construction of an audio distortion analyzer with my friend Janne, the question he posed was clear: why couldn’t you build one simply with a high-quality DAC and ADC?

The main usage I could foresee for such a tool would be to measure other codecs, and perhaps some simple analog circuits. Most of the reasonably priced audio codecs are specified with a dynamic range of some 100-110 dB, and a THD figure of about -100 dB. The analyzer would have to be quieter and more linear than that, preferably with a dynamic range and THD of at least -110 dB. Are there any such codecs available?

Even then, would the analyzer be accurate? Would it be possible to say anything about the reliability of the meter circuit without any special (very expensive) calibration tools?

THD analyzer environment diagram

The above figure shows the major parts of the setup. A probe signal is first produced by software running in the THD analyzer, converted to an analog signal, and sent to the DUT. The DUT does its job, and the analyzer section records the result. Once enough data has been collected, the software filters the recorded signal with a notch filter to cancel the original probe signal, calculates the power spectrum of the residue, and finds the distortion peaks in the power spectrum. Easy.

Since both the generated and the recorded signals are known, it is easy to estimate the frequency response of the analyzer itself with a simple loopback connection. On the other hand it’s not so simple to tell if the amplitude of the generated signal is correct, but it can be calibrated to a sufficiently high accuracy even with just a cheap oscilloscope or multimeter. As a bonus it’s relatively easy to measure the total delay of the signal through the full signal chain, and also here the analyzer’s inherent delays can be measured with the loopback. Many audio codecs can run at 192 kHz sampling rates, which would allow measuring even high (audio) frequency distortion.

I’m only interested in measuring low-voltage electric circuits, not power amplifiers, so the codecs must be interfaced with analog circuits on the normal line levels. The analyzer hardware itself turns out to be just a simple audio interface without many thrills. But with which codecs?

The major high-end codec manufacturers are Analog, Cirrus Logic, AKM, and Texas Instruments, and after comparing their offerings two chips stood out.

Burr-Brown’s PCM1792A boasts an insane -132 dB dynamic range and THD+N of 0.0004%. Analog’s AD1955 was another option, but the PCM1792 datasheet has a nice-looking schematic for the output line amplifier.

The ADC would have to be either AK5388AEQ, which is a very high quality 4-channel ADC, or PCM4220 with a slightly lower spec. The AKM chip looked much more interesting, as it also came with nice schematics (that turned out to have errors in them) and the whole idea of using a 4-channel ADC to sample a mono input seemed sufficiently overkill to me.

Wait, what was that about feeding one input channel to a 4-channel ADC?

Multichannel codecs

Since the DAC has two channels, these can drive the positive and negative lines of a balanced audio interconnect separately, doubling the maximum output voltage. Theoretically this also gives an easy way to double the dynamic range of the output. Each DAC channel is also balanced to maximize the dynamic range of the codec, but it seems that the best use for these is to drive a preamplifier.

The ADC circuit is only slightly different, but since the input amplifier is actually reducing the input signal level (from +-13V!) to a range the codec can work with, it is possible that the preamplifier opamps may contribute significant amounts of noise. To avoid this, two sets of opamps are placed in parallel. The noise from the opamps will be uncorrelated, which can be exploited to increase the dynamic range theoretically by -3 dB. The opamps on the positive and negative sides of the balanced interconnect also mix the same way, reducing the noise floor by another -3 dB. To make use of the 4 ADC input channels, the output of each opamp pair is fed to two channels, allowing the software to sum the inputs to reduce the codec’s noise floor (if it’s uncorrelated between the channels) by -3 dB. This looks too good to be true; it can’t be this easy.

In principle an unbalanced output can be produced by sending a zero signal on the negative output. And the input should be able to deal with unbalanced inputs too, as the negative side will just be grounded. Well, that may not work so well due to many reasons, but balanced lines are good enough to start with.

The software is trivial.

Let’s build it!