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 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.
The ATtiny85 is one of the smallest microcontrollers in the AVR ATtiny series. In a SO-8 package it’s the size of a small opamp, perfect for tight boards. It’s not much of a beast though, with effectively only 5 free I/O pins, but surprisingly often that’s just enough.
Tiny MCUs like this come especially handy for prototyping, where you might just want to try something that needs a couple of control voltages, and the bulky Arduino is already hooked up to some other ongoing project. So I drew up some breakout boards and ordered them from DirtyPCBs. Leds and buttons come handy too, so I added one of each…
Since most forces will be exerted on the ISP connector and the button, I placed those in the middle of the pins. The ISP connector has the standard pin layout, and any AVR ISP programmer will work. Most components are 0603, only the 10uF cap has a bigger footprint.
Only one of the two resistors “RESET H” or “RESET L” should be placed; “H” pulls reset up to VCC, “L” down to GND. I used 10k for these. R1-R3 can be smaller, such as 1k ohm; these resistors are in place so that the ISP connector can work correctly when the board is connected to the prototype breadboard.
My breadboard prototypes invariably turn into these messy knots of wire… here the ATtiny85 drives an ENC28J60 ethernet controller (and some extra stuff):
You have to start somewhere. Audio effect design is a lot of fun, but you need an idea to pursue. It doesn’t have to be anything complicated – that will come later on its own – but it should be concise. Having no deadline helps a lot: there’s no one but yourself to please, and you get to choose yourself which corners to cut. But then what, how can that be turned into something that blinks and makes noises?
I have wanted a good delay effect box for a long time. There are uncountably many delay plugins out there, but hardware has its own merits. I had experimented with the concept of deeply modulated delay lines several years ago in a buzz effect called “ld zdelay”, and it would be lovely to have something like that in my hands, in a box.
The whole point of such an audio effect is that it has a lot of hands-on control. The Lexicon PCM 42 and the Moogerfooger delay pedal get close to what I’m looking for; but the very minimum for me is a “studio quality” unit with stereo inputs and outputs. On the other hand this is usually the domain of rackmultieffects, but those come with all kinds of complex menus, often controlled with buttons or an encoder knob, and perhaps three direct control knobs, if you’re lucky.
Mine should fit in a one rack-unit high box. Each parameter should have its own knob. Stereo inputs and outputs.
So I have a basic concept. But I could easily improve on it: I also want to have an external effect insert point in the delay feedback loop, so that it’s possible to experiment with all kinds of eq and distortion pedals. And the dry signal thru should have no delay to it; it’s an “analog” box after all, and this is easy to achieve in a delay effect. Digital devices always add some latency – inherent delay in the passed-through sound – due to their ADC and DAC codecs. The amount of delay depends on the codec design, but it’s always there. In a delay effect it’s especially easy to compensate for these, as the purpose of the effect is to delay the sound and then mix it to the incoming audio signal again at a later time. It’s enough to take the codec latency into account when calculating the digital delayline length. But if the dry path – the direct through path – is supposed to be analog, it means that the final dry/wet mix knob must be analog too. This is getting interesting…
In attempt to turn these thoughts into something more concrete, I started by drawing a picture as usual:
These pictures of mine are just initial sketches, and I rarely plan ahead of time to put them anywhere visible to the public – that includes these pages. There are always many mistakes in the pictures: the errors are exposed when I draw them out, that’s the intention. In my own projects I seldom fix them up afterwards as there’s nobody to look at them, and they remain dirty and unfinished once they’ve fulfilled their purpose. The best parts will be lifted to the next step in the design.
You can see in the picture that there is clearly a dry path and a wet “fx” path, and that the feedback loop through the external effect (or bypassing it!) is driven by the DSP separately of the main input/output. The basic idea is that the dry main input is recorded by the DSP, delayed, and the delayed copy is then mixed with the dry signal.
There are two mute boxes (electric circuits that can silence the signal or pass it through, controlled by a processor) there already; these are not strictly necessary for a delay effect box, but after finishing the drawing I realized that adding them would make the design much more reusable for different effect configurations. The direct analog dry through could be disabled, and the main output controlled only by the DSP. In this case the mix knob could be left unpopulated on the board. Or the main audio input could be allowed directly to the external insert effect and into the second DSP audio input, for example to use as a compressor sidechain.
This drawing already had something “right” to it, but it still seemed like I could be missing something obvious. All the important blocks were there for sure, but perhaps I could make even better use of them if I allowed some other connections, or set up the signal paths somehow in a slightly different way. One especially glaring omission is that the insert effect may also be very low-latency, but now the signal would always pass through the DSP before it could be mixed to the dry signal, which would always add extra latency to it. An analog signal path through the insert effect would be a nice pair for the analog dry through path.
So I did some more sketches of different possible combinations of dry/wet and direct/delayed signal paths.
I did several pages of similar sketches. In the end I settled on this one, which is more or less a superset of the other designs I could come up with.
The symmetry of the design is somehow pleasing: there are two full, electronically patchable paths from the input on the left to the final mix knob on the right. The wet side sports the external effect insert point, with a switch for feeding the main input, second DSP output, or both to it. The signal from the insert point is fed to the DSP to record the effect. Another switch allows replacing this wet signal with the other DSP output. The dry side is simpler, and the mix knob can be driven either with the direct thru, or one of the DAC outputs. There is a nice symmetry also to the circuitry: the same mute circuit could be repeated to implement the different signal paths. The input signal level control, input panning control, and the final dry/wet mix controls are analog potentiometers. It all looks clean and simple.
I had also been drawing some kind of a front panel design, to see what I could fit on the panel and what would have to be left out. The emphasis was on direct control, so every button and knob should do one thing, without exceptions, and do it well. Ok, some buttons could do many things if you pressed them in combinations, but it would be best to be cautious and not overdo that. A display of some sort would be nice, to show the delay time (which is important) and perhaps some other parameter values. The 16×2 LCD displays have become some kind of a standard, and I have those available, so why not. Preset selection buttons would take some space too, but maybe even those could be left out… who needs presets anyway? I’d rather have some more direct control buttons. ;-)
It takes some thinking of how to implement the thing when you draw the front panel: how to wire the knobs and buttons, which microcontrollers are needed, what kind of scanning is needed for the keys and leds, whether to use pots or encoders, etc. I settled with the analog controls on the very left-hand side of the panel, so that those could be directly soldered to the mainboard. The other controls could be placed on their own PCB with some controllers and a flat cable to the mainboard.
At this point I made a software prototype as a Buzz effect plugin.
The plugin is in many ways inferior to the hardware DSP version, but it’s not artificially limited. You can even connect other plugins into the external effect insert loop, and it will correctly compensate for their latency. If you could run it at the intended 192 kHz sample rate with a very low-latency audio interface, it would do perfectly fine. That’s my baseline. And what’s most important, you get to listen to it an play with it (in real time even!) before you put any money in it! :-)
At this stage I felt confident enough of the design to draw a first schematic. It turned out at a full length of 18 pages! There are waaay too many opamps in this schematic to be practical, but it can be optimized further.
The audio path is the same as above, but now it looks like this. What a difference! But this should be perfectly “possible” to build.
One of the most important steps in the schematic drawing process is the assignment of CPU ports. All modern processors allow dynamic assignment of their pins to the internal peripherals’ ports. Some CPUs allow more freedom, some less. I like the NXP LPC176x, it has a lot of different capabilities and it often allows assigning the peripherals on at least two different sides of the chip. The Freescale DSPB56724 is not that flexible, but it’s incredibly well designed and usually fits perfectly without much trouble. DSPB56725 is a smaller and cheaper version of the same DSP chip, but this time I’m going for the big brother because it comes with a full SDRAM memory controller. (This is in fact how I got started, I wanted to try out the memory controller to see how difficult it is to use.)
You really want to read the datasheet carefully when doing this, and make use of all of the flexibility. Some peripherals can use signals from each other. For example, an I2S receiver and transmitter often allow sharing the same clock signals, so it’s unnecessary to duplicate these wires on the PCB. I drew the above picture to keep track of the already allocated pin groups, and the picture below was the sketch of the possible circuit board layout.
With this I could start working on the PCB layout. My analog design is very hierarchical, and I use DipTrace, so I could lay out and route a single block at a time, applying the same work to all identical hierarchy blocks. This saved a lot of time, but left me with a disconnected set of small circuits. From then on the drawing becomes more difficult to modify as the board will be very crowded. It looked like I would have to plan ahead again, this time for the analog side.
I took out all the hierarchy blocks for the analog part on sticky notes. These are the same blocks as in the analog signal path schematic a few pictures above, with their inputs and outputs marked on the pieces of paper. Then I rearranged the stickies on a bigger piece of paper, and drew the signal bus connections between them. At one point I realized a mistake and had to backtrack and start again, but eventually I found a combination that had sufficiently few overlapping lines (i.e. wires on the PCB) and that had the right shape. The shape matters, as the PCB has rather tight size constaints (bigger boards become very quickly also much more expensive), the components all take their own amount of space and cannot be compressed!
The previous CPU layout picture gave the full left side of the board to analog circuits. This sketch fits there: notice the codecs on the right (with the DSP then behind them), the knobs in the bottom left (front) corner to fit the front panel, and audio inputs and outputs at the top (back of the device).
Armed with this, it’s finally time for some real PCB action. I’m not done optimizing the schematic yet as I write this, but here’s how it started. It’s still a long way before it’s done… somehow I will have to reduce the size to at least half of how it looks here!
This is an example of my own, personal workflow: I try to find ways to make things easy to see quickly for myself, but that doesn’t mean that the same approach will work for everyone. I don’t have to please anyone else with these designs, so there is no need to stick to any “standard” style of drawings.
Try to figure out what kind of prototypes and visualizations are best for yourself, and don’t be afraid of iterating over and over again. If you can think of a way to visualize your ideas, try it out right away. It costs nothing and takes only a short time. If it comes out wrong, draw it again and again. If you can think of many ways to draw the same thing but perhaps from a different angle, do both or all, and compare them when you have them side by side. It’s also easier to come back to drawings on paper the following day, instead of trying to remember your thoughts with no reference.
It’s the realtime aspect of games and musical instruments that gives them their universal appeal. People can’t stand tools that do not respond in a timely manner, be it software or hardware.
So what happens then when you take something so profoundly clunky that everyone is accustomed to it, and embed the idea of a realtime feedback loop in it? Your users get to travel freely from one parameter set to another. And they will find it much easier to reach interesting parameter subspaces and their sweet spots.
This alone is often enough to turn a complicated-looking system into a playful toy.
Of course, sometimes you still end up wishing everyone had a supercomputer for the number-crunching.