SquishBox

Now that I've got kits for the SquishBox up on the Tindie store and build instructions for that hosted on Geek Funk Labs, I've posted complete DIY instructions here on Hackaday for anyone who wants to build their own SquishBox from scratch. Good luck and contact me if you need guidance!

I've opened a Tindie store for selling a completed version of this project, which I call the SquishBox. Updated code and info can be found at the GitHub repository. Yay!

I bought a Raspberry Pi 3 for the speed/memory upgrade. Since the GPIO header is the same as the Pi 2 I was able to just swap it out with the Pi 3. With the faster processor I was able to tweak fluidsynth's settings (audio.period-size: 64, audio.periods: 3) to get even less latency. I didn't really notice a delay before, but playing through the jamPi definitely "feels" more responsive now.

A couple other minor points of progress:

• Updated pyfluidsynth with bindings to fluid_midi_router.c - router rules can be set up in config_jampi.yaml
• Expanded structure of config_jampi.yaml and how it is interpreted by jampi.py:
  • settings:soundfont: global soundfont to use in patches if per-channel soundfont isn't specified
  • settings:fluidsettings: passes options to fluidsynth
  • router rules can be specified globally (in settings) on a per-patch, or per-channel basis
• I read the soundfont 2.1 spec a bit more carefully and realized that modulators can be used to allow CC messages to control things like filter cutoff, resonance, etc. Fluidsynth already understands modulators, so I can use the built-in synth capability of soundfonts without rewriting fluidsynth. To test this, I used Polyphone to make a soundfont with one saw wave preset and modulators tying the filter resonance and cutoff to CC 71 and 74, and it works! Boss.

Time since the last update has been spent coding a smooth interface for the jamPi, coming up with a logical format to store patches, debugging to make sure there aren't too many crashes when I'm playing live, making sure there is always a way to get an ssh so I can make changes/debug if things go bad without taking the thing apart, and painting the box. I'm fairly confident this is at a state that people can actually use and make their own modifications from, so I'm posting the code in its current working form and will add some actual instructions soon. I have more mods planned to maximize this thing's potential (and fun), but they will all be software updates that can be pushed in via ssh.

Painting stompboxes in a way that is durable and pretty is apparently an arcane artform that I may never have the patience for - if you don't believe me check out the forums on diystompboxes.com (which were incredibly heplful despite my failures). I failed with my initial paint job - the clear-coat ate my cheap cranberry 2x spraypaint and crinkled it up like a wadded paper towel - so I had to sand the whole thing and try again. Second try I used some automotive primer and a hammered-finish spray. That might have been enough, but I sprayed some clear lacquer over the top for some additional protection. Not sure if it helped or hurt - you can see some dents in the finish already from where it rode in my gig bag and some squishing where I tightened down the stompswitches because I'm impatient - there's no way I'm going to wait three months for the paint to cure or bake this thing in a toaster oven as some suggest. I decided to go with the punk cred and lettered on it with a white correction pen why not.

The interface takes about 15 seconds to come up. I had it coming up in about 4 seconds by having systemd run it as a service, but fluidsynth wasn't able to start the audio driver. Hopefully I can figure this out later - in the meantime I may have a small script turn on the LCD at boot. The patches consist of global chorus/reverb settings and soundfont/bank/preset settings for any of the 16 MIDI channels. I plan to add a feature for reading midi routing rules out of the config_jampi.yaml file, but I'll have to add those bindings to pyfluidsynth first. A menu can be reached by holding either stomp switch for ~2 seconds - this allows you to update the patch (if you've changed a program or chorus settings, for example), save a copy of the current patch as a new one, reconnect a midi controller if you want to swap or didn't have one connected at boot, and control the wifi adapter. Holding down a stompswitch for ~5 seconds gets you a shutdown prompt. Stomping for 2 seconds confirms. I've yanked the plug on my Pi's many times without ever corrupting an SD card, but better safe than sorry.

The wifi control is a bit unreliable. I have the Pi always boot up and connect to my home network for now so I don't get locked out - if I couldn't get a wifi signal I'd have to open the box, disconnect the Pi and plug in a keyboard/monitor or console cable to fix things. I installed hostapd and dnsmasq so I can connect to the Pi as an access point if I'm out somewhere with it, and this seems to start fine, but I can't dynamically switch between using hostapd and connecting to my home network like I want. I think I need to turn off network autoconfig (ifplugd something something) and learn more about manually configuring wlan0, but that's for another day. There is also a 'wifi off' option - sometimes the adapter makes some minor noise that gets into the audio signal.

I want to add a midi learn feature, but that requires modifying fluidsynth itself to echo received midi messages, and adding bindings to pyfluidsynth. There already is a debug function in fluidsynth for this that goes in the right direction, but I also don't want to slow my script down by making it listen for midi messages all the time, so that will take some cleverness. There is also the project goal of being able to change the filter (resonance/cutoff) settings used by each soundfont on the fly, like a real synth - but this requires adding an entirely new feature to fluidsynth, and I'm not 100% sure it's something you can actually do.

So, in summary - I've got a working stompbox synth, but there's still plenty of fun hacking to be done with it!

Punchline first - got everything to fit inside the box, and it appears to be working (mostly) as intended. Video evidence:

I realized I'd have to do some reconfiguring to get everything to fit inside the stompbox. I made a couple USB extender cables out of some ribbon cable to connect from the Pi's USB ports to the MIDI in port on the hat and to the little USB sound card.

I also pried the case off the sound card so it would take up less space. Wrapped some pretty orange duct tape around a couple things to prevent things from shorting to the case, and crammed everything in the box. It's a pretty tight fit:

But it works! I've got jampi.py set up as a service so it starts up quick when the box is plugged in. There's something goofy in the code where the buttons register an event on both press and release, and I have many more plans for the interface code (and for modding fluidsynth itself), but progress is being made!

Soldered the rest of the components onto the proto hat over the weekend. Used a short length of USB cable from the jack on the hat to the one on the Pi - had to really fuss with the length, and ended up making it almost too short, but it works. The jacks, wires, and components sit kind of high on top of the hat, but I think it will all fit inside the box once I cut the holes.

Changed some of the pin numbers in the code to match where I connected the necessary LCD pins and buttons, and added some code to use the Pi's built-in pull-down resistors. Turned it on and ... it's alive! I plugged in some headphones and the MPKMini2, and I got piano!

Next steps: cut holes in the box (+sweet paint job), make some tweaks to fluidsynth, and write really nice interface code for my python stompbox.

That was a big waste of time. The USB cable I was testing with must have a short or a bad connection in it somewhere. I got frustrated and cut up a new one, and the Pi powers just fine off of 5V into the expansion header. Tried a few different power supplies just to be sure. This is good, though - fewer cables in the box and more space for buttons/jacks. Blerg at least I can sleep now.

I soldered the USB jacks for power and MIDI controller onto my perma-proto hat. I shelled out $6 for one of these because it's got pads on both sides - needed so I can solder the jacks on top where they'll fit - and it's sturdy and has mounting holes to hold everything together. First thing I did, of course, was break it. I drilled holes for the little anchor tabs on the USB jacks, and the first hole in the ground rail next to the 3.3V rail is where the trace from the header is connected. No biggie, since there's another ground rail by the 5.5V rail.

Fitting things into this box is going to be tricky. I'd hoped to chop the end off a micro-USB cable and wire it to the B-jack to get power to the Pi, but it's a tight fit even with some of the plug sliced away (the laptop PSU is just photobombing - not part of the project).

I put the voltmeter on the pins and saw that the voltage was fluctuating rapidly between a few tenths of a volt and maybe 4.5 volts. I imagine what's happening is that the Pi is beginning its boot sequence, and the switching voltage regulator in the 5V adapter is not keeping up with the current demands. The Pi decides something is wrong and shuts down. Then, current from the adapter ramps up and process repeats. The electronics in a console cable must be better able to handle this.

I took a look at the schematic for an FTDI cable and saw all those filtering capacitors sitting on the 5V line - maybe they filter out those rapid changes in current demand. I tried to copy it on proto (I know a coil of wire does not a ferrite bead make, but EMI shouldn't be a huge problem here).

I was able to pop the casing off the microUSB cable plug, so I should be able to go that route after covering it with some shrink tubing. Probably the safer option, but I would like to know what makes my FTDI cable so special.

I initially spent some time playing with sound cards and with Fluidsynth to see if it could be used reasonably in live performance. The Pi's built-in sound jack is right out - my web research tells me the Broadcom chip downsamples audio to 11kHz, which sounds unacceptably crummy on many patches. I thought it might have lower latency, but this is not the case. With the right buffer/period settings (will provide later) on Fluidsynth the latency is not noticeable and the sound through my little USB sound card is actually pretty decent. The one horrible thing that does happen is that if you mash a lot of notes at once (10-12), Fluidsynth gets overloaded somewhere, and rather than simply dropping notes it produces horrific digitized car crash sounds until you stop pressing keys for a few seconds. Maybe some kind of memory overload? I couldn't find any help on this issue (please advise if you know what's going on) and haven't had any luck fixing it myself, but after a while I decided maybe I just don't need to hit 10 notes at once.

I did some prototyping to make sure I knew how to wire buttons and a character LCD, and that my python script didn't interfere with Fluidsynth. I had to add some bindings to pyfluidsynth to start up the MIDI driver and router - apparently it was just designed for people who want to play MIDI files. I did some jamming with my proto board synth, and everything felt and sounded good, so I proceeded to work on putting things into the stompbox.

There isn't a lot of extra space in the box with the Pi, proto hat, LCD, stompswitches, and various connectors in there. The USB-B power jack and USB-A jack for midi controller will be soldered onto the proto hat for stability. I plan to anchor the proto hat to the box with standoffs, then the Pi will be held in place with its GPIO connector and additional standoffs. I need to get USB from the Pi's ports to the sound card, and to the USB-A jack on the hat, and there's barely any space in the box over there, so I will fashion my own short right-angle USB cables by cutting down a couple USB plugs as small as possible, soldering on wires, and shrink-wrapping.