MT32-Pi (or MiniDexed) - The best cheap synth value around

Like pretty much everyone else, I decided to get into synths during the COVID lockdown period, but seeing as I'm a cheap bastard, I wasn't too excited about dropping $300+ on each piece of gear and started looking for cheaper ways to explore the hobby. I figured there was sure to be some mostly turnkey, DIY solution based on an Arduino or Raspberry Pi that would give me a quick, low-latency, headless and flexible (and good sounding!) MIDI-controllable synthesizer that I could just flash onto an SD card and be off to the races.

It turns out that this is much more difficult to find than one would expect.

Almost everything I could find is limited and/or poor-quality (everything Arduino-based) or unusably latent and/or extremely difficult to use and set up (everything RPi-based with JACK). RPis also have pretty crummy audio quality from their built-in 3.5mm headphone jack, but that's a minor gripe vs getting it to work at all.

However, I had the astonishing stroke of luck to come across a wonderful, free, open-source project that was just maturing to the point of usability when I was looking, and it checks all of my 'required' boxes and more: mt32-pi.

EDIT (5/30/2022): For the past few months, I've been using another excellent and new (at the time of this writing) software called MiniDexed, which also fills this same niche, but is based on the legendary Yamaha DX7 FM synth. Check it out!

This project describes itself as "a baremetal kernel that turns your Raspberry Pi 3 or later into a Roland MT-32 emulator and SoundFont synthesizer based on Circle, Munt and FluidSynth." For those who aren't familiar with the MT-32, it was a sound generator for MIDI keyboards back in the '80s-'90s but also found success as an ultra-high-end solution for video game audio in the days before CD-ROM soundtracks took over. For a taste of how much better the MT-32 sounded than competing sound solutions, check out this video.

So, just using the built-in MT-32 instruments, you can get some really great, authentic retro sounds, from synth bass to horns to percussion. Mt32-pi also supports SoundFonts, though, through its FluidSynth mode, which really opens up your possibilities to basically anything you could ever want. And, since it runs baremetal, there's no OS running in the background, no ALSA adding latency, no hassle of setting up a JACK server and wondering why your sound doesn't work, etc. It boots up in just a few seconds (it takes about the same amount of time as my pedalboard) and responds with live-performance-friendly low latency.

It seems most of the buzz surrounding this project comes from its usefulness as an outboard sound processor for the (fantastic) MiSTer FPGA retrogaming platform, which doesn't have the resources to do good MT-32 emulation on its own while also emulating the original PC 486 hardware needed to the play the games in the first place. For this reason, if you just go searching around, you'll likely find that most of the information and accessories (there are a number of places selling cases and hats, etc.) are catering specifically to this purpose/market rather than music/performance, but the mt32-pi project's wiki includes plenty of information to track down or build your own, should you feel the need. (as an aside, the mt32-pi developer, d0pefish, didn't even realize there was a demand for the retrogaming aspects of the project, as he created it purely for music/performance purposes, just as it was with the original MT-32)

In my case, I felt the bare minimum was a cheap OLED display (SH1106 and SSD1306 models are both great, simple and compatible options available for $2-$8 on eBay/Amazon/AliExpress) and a couple of arcade buttons to control the mode (MT-32 vs FluidSynth) and to cycle through the available SoundFonts (loadable from a hot-swappable USB drive). I also use an I2S DAC for better sound quality (again, $2-$8 from eBay/Amazon/AliExpress), but you can get by with the built-in if you don't mind occasional crackling in quiet parts. All of this is connected directly to the RPi's GPIO pins via dupont connectors.

I also found the gain to be a bit too low vs my other equipment, so I pair it with a cheap headphone amplifier I built to give it a little more grunt (the popular KKmoon kit is good for this, but I went for the 47 HIFI NE5532 kit instead, as it has more robust thru-hole soldered I/O jacks, which will stand up to repeat plugging/unplugging better than the KKmoon's fragile surface-soldered pads). You can't really see it in the pic as it sits directly underneath the RPi and is almost exactly the same dimensions.

Many of the available hats include full-size MIDI DIN connectors, but you can also use any standard USB-MIDI interface/breakout. In fact, I control mine through an Arturia KeyStep (which is an incredible value in its own right) plugged directly into the RPi's USB ports. That is, both devices are connected via USB-MIDI, with USB on both ends; no actual MIDI ports involved, which leaves those ports free on my KeyStep to control other things, like my Roland TR-08 drum machine. I do get some occasional weird behavior (some stuck/dropped notes) with this setup, though, which I think is caused by the KeyStep pulling too much voltage.

So, between the KeyStep and the RPi plus accessories, my full kit costs somewhere between $150 and $200, with the vast majority of it coming from the KeyStep. This is in-line with Korg's Volca line of products (which are great!), but with more power/flexibility in some ways (the KeyStep has an amazing arpeggiator and powerful sequencer and it can serve as the timing heart of your entire setup, while the Volcas' sequencers are simplistic and lack arps entirely) though admittedly less in others (i.e., no knobs to sculpt your sound on the fly; however, the staggering number of SoundFonts available means the Volca FM's compatibility with DX7 patches makes it the only cheap synth with comparable breadth of sonic possibilities). If you already have a MIDI-capable keyboard/controller lying around, you can get the whole thing going for sub-$50, which is simply impossible to beat, value-wise, and if you're already an RPi enthusiast, you may have everything lying around on your workbench already.

Raspberry Pi 240p Composite Output

Big news for emulation on Raspberry Pis of any generation: a new firmware update has enabled 240p output through the composite video-out port (a dedicated port on older models and a combo 3.5 mm jack on newer models).

From Raspbian and its derivatives, you can run from a terminal:

sudo rpi-update

and it will automatically install the new firmware. For Lakka, the updated firmware will make its way into the main release at some point, but in the meantime, you'll need to mount your SD/microSD card on another machine and then find the 'boot' directory (for Lakka, this will be located in the ~500 MB partition that holds the system files rather than the bigger partition that holds your games) and make a backup in case anything goes wrong (not likely, but better safe than sorry).

Next, you'll need to download the new firmware files from github (here's a direct link to a zipped download) and copy them into the boot directory, overwriting what's already there. I believe you only really need a subset of the files (bootcode.bin, fixup.dat, fixup_cd.dat, fixup_db.dat, fixup_x.dat, start.elf, start_cd.elf, start_db.elf and start_x.elf), so if it acts strangely, maybe try cutting down to just those files.

In your config.txt, you can use the sdtv_mode directive to change to the new modes (either NTSC or PAL):

sdtv_mode=16    # progressive NTSC
sdtv_mode=0x10  # progressive NTSC (using hex notation)
sdtv_mode=18    # progressive PAL
sdtv_mode=0x12  # progressive PAL (using hex notation)

Also, make sure your config.txt isn't forcing HDMI output via hdmi_force_hotplug=1 (comment it out, if so) and you might want to force composite output, just to be sure, by adding hdmi_ignore_hotplug=1.

Raspbian and derivatives can now also change modes at runtime using the tvservice program:

$ tvservice -c "NTSC 4:3" ; fbset -depth 8 ; fbset -depth 32; tvservice -s 

Powering on SDTV with explicit settings (mode:0 aspect1)state 0x40001 [NTSC 4:3], 720x480 @ 60.00Hz, interlaced

for interlaced mode or:

$ tvservice -c "NTSC 4:3 P" ; fbset -depth 8 ; fbset -depth 32; tvservice -s 

Powering on SDTV with explicit settings (mode: 16 aspect:1)state 0x40001 [NTSC 4:3], 720x480 $ 60.00Hz, progressive

for 240-line non-interlaced mode.

Now, you'll notice that the above line still says 720x480 and applications will still see a 480-line resolution (that is, emulators will want to run at 2x scale). That's because the firmware still acts like normal 720x480 (or 576 lines for PAL) and the composite encoder just displays only half the lines.

This is actually to our benefit because it allows us to easily go back and forth at runtime and has the potential for on-the-fly switching (though RetroArch/Lakka doesn't support that and probably never will). It also allows emulators to show interlaced content without freaking out (that is, a "true" 240p resolution would cut off half of the picture, while this setup will just blank out every other line, which is much less obtrusive).

I have some pics here but, hilariously, the one from the new firmware turned out the worst:

RPi 240p Composite

Analogue Nt - RGB-PPU YPbPr

RPi 480i Composite

If you look closely, you can see that the RPi 240p shot has gaps between each scanline (easier to see on the green waves of the hill than on Luigi), while the 480i shot does not. What the still image can't show is that the 240p image is rock-solid stable, while the 480i image flickers sickeningly. Either way, the RPi composite output obviously does proper NTSC encoding, so blending of dithering and so on happens automatically without needing a shader, which is nice. EDIT: the NTSC encoding is (obviously, in retrospect) using the RPi's full 720 horizontal res timing rather than a console's native timing, so effects that depend on NTSC artifacting may or may not look like you would expect. For example, here's what the "tvpassfail" NTSC test ROM *should* look like:

NTSC Pass/Fail test ROM with maister's NTSC 256 px shader

But this is what the RPi's composite output actually shows:

NTSC Pass/Fail test ROM via RPi composite output

There's still crosstalk, of course, but it's spread across more pixels, which breaks the test. Perhaps unsurprisingly, it looks closer to the 320 px NTSC shader output:

NTSC Pass/Fail test ROM with maister's 320 px shader

With this new firmware, the RPi3 is now arguably the best/easiest/cheapest way to do proper 240p emulation on a typical NTSC standard-def television. Previously, a softmodded Wii was the undisputed champ in this area, as it was the only way to do 240p without putting a series of adapters and converters in the mix. The Wii still has an advantage insofar as it can output a high-quality YPbPr signal (i.e., comparable to the Analogue Nt shot above) but the RPi3 has the ability to emulate more consoles, including great Playstation 1 emulation via PCSX-ReARMed and decent N64 emulation via the core formerly known as GLupeN64 (now renamed to just Mupen64Plus-libretro). The Pi2SCART add-on from ArcadeForge can get a cleaner, "pixel perfect" output from emulators on the RPi, but at ~$50, it costs significantly more than the RPi itself, costs as much as a used Wii and requires adapters to work with standard NTSC televisions. So, in my opinion, RPi is the way to go for cheap/easy "240p" emulation on a regular ol' U.S. TV, while the Wii is a step up in visual quality but more of a hassle (and fewer games/consoles available to emulate). Pi2SCART wins in both respects but also adds significant cost.