A few new sound clips: the first one is another experiment with the oscillator pitch shifting, tuned to sound like inharmonic overtones. Just three oscillators, all parameters are constant. There is no chorus effect, no LFOs, all the movement is coming from the oscillators!
The second one is a very plain goa riff loop, playing with the filter and oscillator waveshape knobs. It starts slow, but once it gets going it’s unstoppable.
The last clip is a repeating bassline (from a game that was very popular in its time, I have to add) with again just one single oscillator producing the sound, with the synth in monophonic mode. Enjoy!
Reverb and delays provided by Lexicon as before.
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!
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.
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.
Christmas came and passed, and I’ve been busy working on the panel. And there is indeed progress!
I was so excited to see how the red front panel design would turn out, with all the graphics and all. The shipping was not so smooth this time, yet it still only took three weeks from the order for the finished boards to arrive from ITead. The quality of the boards is high, as good as ever: just perfect.
There’s only one problem… these boards aren’t red!
Uh-oh. Somebody messed up my order, and now I have a bunch of green boards instead. These aren’t good at all for a translucent plexiglas box, as the green color would just make the whole setup look like a very early prototype, instead of the soundbox-to-get-your-hands-on that it is. ;-)
Luckily Stijn was there to cut me a very nice panel out of thin MDF – thank you! It fits perfectly, and I can still paint it red. Maybe I could make a full box out of this stuff, instead of just a pair of sheets for mounting the prototype… Heck, this might still turn out very nice!
It’s surprisingly difficult to mount all the controls on a single board in such a way that they end up level on the top of the panel and not sticking out too far. The reverse through-hole potentiometers are perfect for this. The encoders can be mounted the same way, albeit only by bending the pins carefully.
The led power supply regulator is still missing in the picture below. It seems to be necessary as I expected: the leds can easily suck enough current to cause the 3.3V level to droop, at least with the relatively weak Arduino power supply that I used for the first tests. And when that happens, each and every potentiometer will momentarily change in value, yuck.
But it works, everything works!
With the separate 9V power supply, and a bit of hacking, it took no time to get the board up and running. All knobs work, all buttons work, all encoders work, and all leds work. The joystick works, too. And the ATmega48 is more than sufficient for all this. Awesome!
The first prototype for the synth front panel is ready in all its glory! (Click for a bigger version – for some reason gerbv drew weird stripes in the ground plane)
Yes, it will be very red! The plan was to put this in a translucent, perhaps milky white, plexiglas enclosure, and the color would then hopefully shine a bit through…
Now, that’s a lot of controls there on the board. 26 potentiometers, 10 encoders, 12 buttons. And the connectors on the left side connect to two more buttons and a joystick. And a 400×240 RGB touch screen in the blank hole in the middle! Here’s a first sketch of what they could be used for, in a cryptic slang (sorry, no SD on the board, please ignore that):
Time for some more protosynth sounds! The first clip demonstrates how a complex audio source like the protosynth can make a reverb sparkle and sheen. You’ll notice it when the reverb is inserted. This one is with the same PCM80+MX200 combo as the previous ones… I think.
The second clip is all about the oscillators again: most of the time it’s just one oscillator – plain with no further effects. And the synth has three of those… per voice. No external effects used, not even the PCM80. The reverb is internal.
I finally managed to record some of the sounds over the period of last weeks. These all feature the protosynth recorded through a Lexicon PCM80 reverb, and some of them also feature a Lexicon MX200.
I won’t argue if you think these sound more like a demo of the PCM80… it’s an awesome reverb unit!
The RPC is a MIDI controller and implements the age-old 1980s serial MIDI bus, and the Protosynth must be capable of interfacing with it. But in general use a USB device port is much more practical than the three ubiquitous MIDI ports; it allows connecting the synth directly to a laptop or other computer at any time. And USB host ports are starting to become popular in sequencers also. So that means I need an interface module that has both, and that can talk to the main synthesizer board over two serial buses. The mainboard processor must take care of interleaving the commands received over the two buses.
Standard MIDI ports are no problem, I had the basic circuitry working with the RPC and could simply lift it from there. The synth’s LPC1678 microcontroller has several UARTs, and it’s very easy to configure them according to the MIDI standard. USB was going to take some more work though. I didn’t have enough space on the DSP mainboard to make use of the LPC’s built-in USB controller, so I decided to keep it that way and went for an off-board solution. My approach was to build an external board that could speak MIDI over USB, and pass the data stream over an UART to the mainboard.
Luckily USB-capable microcontrollers are a dime a dozen these days, so it’s only a matter of choosing a suitable one for the purpose. A little bit of searching found me MocoLUFA, which is a complete implementation of a standard MIDI USB device for the ATmega, created by morecat_lab. The ATmega8u2 it was intended to be used with looked very nice, and its bigger brother ATmega32u2, while pin compatible, would have plenty of capacity for future expansions if necessary. The Arduino Uno is one example of the use of these chips; the Arduino team very successfully replaced the previous FTDI USB controller with an ATmega8u2 to reduce the cost of their boards. With inspiration from the Uno schematic and from the ATmega32u2 datasheet, I drew up the first version of the MIDI board.
The design was straight-forward. I used the 4N28 optocoupler and through-hole components for the MIDI side because I had those at hand. Except for the bypass capacitors. I have a lot of 0603 size 0.1uF caps now! :-) In the default configuration (F1 unpopulated in rev2 schematic) the device is self-powered: it will NOT draw its power off the USB bus. That means the it will disconnect from the computer when the it is powered off, as expected for a stand-alone device. It requires an external 3.3V power supply, and the signal voltage for all communication to and from the mainboard is 3.3V. The MIDI DIN5 connectors are very close to each other in the first revision of the board; while there are some DIN jacks that should fit, I dragged them a little bit apart for the second revision. Almost all of the GPIO pins on the ATmega are wired to am extra pin header next to it. Four are connected to SMD LEDs.
The ATmega8u2 does not have a dedicated VBUS pin for detecting whether it is connected to a USB host or not, and the MocoLUFA software can be configured to use some other GPIO pin for this purpose. In the end I left VBUS unconnected, because I wasn’t sure if the ATmega could handle overvoltage on the pins. The data sheet indicates this should be avoided. The USB firmware still works, albeit not completely according to the standard.
The two serial buses connecting the interfaces to the mainboard run at different bitrates. The real MIDI interface must be configured at 31250 bps. The USB interface doesn’t seem to have any such limitation, so I set it to 125 kbps. Just because it was a nice round number with the ATmega running by a 8 MHz clock. I’m not yet sure what kind of flow control the USB bus is capable of…
For programming the ATmega you will need an AVR programmer that can be hooked to the 6-pin ICSP port. I used a 5V Arduino Mega 2560 with the ArduinoISP firmware installed on it. The supply voltage of the Arduino is not an issue as long as you keep the MIDI board otherwise completely disconnected during programming. The MIDI ports are designed for a 3.3V power supply, so if they are powered by 5V they may fry any connected MIDI devices! During programming the board will draw power through the ISP port.
I will add the gerber files and BOM here later. Drop me an email if you’re interested in them or the Eagle source files (see bottom of page for the address). I have several rev1 PCBs left, and will most likely solder together at least a few more if all goes well. There are many possible interesting configurations of the board. For example, if the ATmega32u2 is sufficient for your application all by itself, the MIDI ports could be connected directly to it… How about a stand-alone arpeggiator board?
Note to self: read datasheets carefully. I managed to mix up the codec clock multipliers, and ended up running the codecs at twice the rated speed. Weird effects ensued. Oops.
Here’s a picture of the sample clock (yellow) and frame clock (blue) generated by the CS4271 if you pass it an MCLK twice as fast as the maximum it can handle. The signal bandwidth is limited by the scope probes, but what’s that tick there…?
So, Huhta noticed first that the clock was too fast, and after reading the codec datasheet once more very, very, very carefully, it was obvious that the only way to go was to reconfigure the clock rate multiplier of the master codec via its serial control port. In stand-alone mode it simply couldn’t handle the 24.576 MHz clock I was feeding it. The slave needed no extra reconfiguration, it could pick up the new SCLK and synchronize itself with that. So then I only needed a serial port…
I was in a hurry (and lazy as always) when originally routing the board, and since I thought the codecs would run in stand-alone mode, I didn’t bother routing the control port pins. And now I would need them. But I was lucky after all, as there was still a nice place on the board where I could solder the necessary wires to the codec, replacing the resistors that would configure it in stand-alone mode. The problem with that was that the pads in question were on the bottom side of the board, and the MCU, where the wires would go, was on the top… There was nothing I could use for passing through the board but connectors for other peripherals… Except for the ISP port of the microcontroller! So there we go.
Below the FFT of a trivial saw at 10 kHz; for some reason the waveform turns into mush (due to high frequency noise and codec’s lowpass filters perhaps?), but the spectrum analysis still has a nice quiet spot above 48 kHz. The aliased components of the waveform are clearly visible. The sample rate of the signal is 96 kHz. There’s still hope!
Big thanks to Zephod for borrowing the oscilloscope and Huhta for pointing out the root cause of all this!
Time is flying, but the first prototype build is almost complete! Only a few small flaws found so far. I haven’t had time to write any proper software yet, but the board successfully boots the DSPs from the LPC MCU over the SPI bus, and every chip happily talks with the debugger. I think I’m close to the point where only the software side is missing…
Well, the codecs and analog circuits are still untested, so better not celebrate yet. Some pictures of current progress below. The flat cables connect to JTAG debuggers.
I’ve spent way too little time on the RPC itself lately…
Today the first boards for the DSP synthesizer project arrived. Itead studio is really doing a great job with these!
I don’t want to spoil too much yet, but if this works – and probably it’ll take a couple revisions to do so – it’s going to be awesome! The bottom left board in the photo is the main DSP board with three Freescale DSPs and an NXP LPC176x. I wanted to start with something that I might possibly have a chance with, so most of the LPC features went unused for now. I also simplified the I2S buses from original plans to keep it simple. Two codecs just because I could.
On top left is the analog side with opamp filters straight from the codec datasheet, and an experimental, simple, and again rather wasteful 9V -> +/- 7.2V power supply to try in case the opamps turn out to require a greater voltage range than just +5V. I ran out of space on the main board, so this second board will be connected on top of it with the audio jacks placed through the large gap at the back edge, hanging from the analog board. And it should be possible to upgrade the codecs to better ones, only requiring a different analog board.
Top right is the MIDI/USB board, with the USB side essentially implementing a USB MIDI interface and talking to the LPC over a standard 31250 bps MIDI serial connection. I went with the 4N28 optocoupler as I had a few of them already and I’m familiar with the circuit. What I’m not so sure about is that I’m going to try to run the MIDI output with 3.3V and suitably adjusted resistors.
Bottom right board is not exactly a part of the synth, but still just as essential. I didn’t have a JTAG debugger for the DSP56k, so I designed one around the Freescale Soundbite schematic. Again, in theory it should work.
I suppose there’s a lot to optimize in the design, but first I want to see it doing something. Ah, so much uncertainty, so much fun to see how it will work out!