SoundFloored: Open Source Soundboard Pedal (Part 1 – Planning)

This is the first post in a series about designing and creating SoundFloored, an open source soundboard pedal! Check out the other posts in the series:

• Part 1 – Planning (you’re already here!)
• Part 2 – Software Implementation
• Part 3 – Breadboard Implementation
• Part 4 – Final Implementation

---

So I’m a guitarist in a band (shout-out to #DemocracyManifest). Not a particularly good guitarist, but nonetheless it’s a whole lot of fun and a great excuse to hang out with some friends for our weekly practice.

One of the issues that we have is that there are only three of us in the band; a guitarist, a bassist and a drummer. This is the dream when it comes to planning practices, but we’ve always had trouble with feeling our sound is “full” enough since a lot of the songs we cover have way more instruments and numerous subtle elements like small synth riffs, choir aahs and audio clips that we can’t really replicate in any appreciable way while trying to also play our instruments.

So “hey” I thought, “let’s try to over-engineer build something that can”!

Requirements

Before we dive in, let’s consider what the end result of this needs to achieve. In regards to overall aim, I’m looking for something that can play arbitrary audio clips on demand to add a bit of texture and depth to our live performances. Some of the specific requirements/constraints I have are:

1. It cannot be operated by the hands (since I need those pesky things to play the guitar)
2. A few different sounds need to be available easily at any given time (no configuring/manipulating anything during songs, need to keep it nice and simple)
3. It must support multiple sounds being played at once
4. It needs to output sound in a format that’s easy to work with on a mixing desk (a common format such as using a 3.5mm or 1/4” inch jack should be suitable)
5. It needs to be cheap (there are products on the market such as drum soundpads that fit into this general niche, but they are pricey)
6. It needs to be robust (both physically since normal usage includes stepping on it repeatedly and in regards to the software since we don’t want it to bug out or crash during a song)

Logic and Processing

So what’s actually going to drive this project? I decided to use a Raspberry Pi for a few reasons:

• I have a couple of Raspberry Pis and various HATs/pHATS available, so there’s no additional cost on that front
• I have very little electronics experience, so the more logic I can push up into the wonderful land of software the better
• There are lots of guides and tutorials available for using Pis with buttons, LEDs, screens and the like, so it’ll be easier to work on the parts that I need to use electronics for
• It gives me more flexibility in the approach I want to take in implementing the whole project (see the “Phases” section further on in this post)
• There’s a built in 3.5mm jack on certain models (like the Raspberry Pi 3 Model B I have on my desk in front of me right now)
• I’ve got some good experience in Python, which has a lot of libraries available that have already figured out how to do a lot of the more complicated functionality

The basic plan is to hook up a series of buttons to the Pi that will be used to control each of the audio clips. The actual processing will be done in Python and most likely use PyGame since it is a well supported library that can play multiple sounds at once out of the box.

I’m going to leave the specific implementation details to when I start working on it; for a bigger project I’d look at architecting the solution beforehand, but by my current understanding the logic shouldn’t be too complex (famous last words etc.). As well as that I’m sure there will be plenty of things that I’ve missed or not considered, so I’d rather not tie myself into a strict design until I start getting my hands dirty.

Physical Design

NOTE: I know you’ll probably want to tell me off for using a ballpoint pen to draw diagrams. I probably deserve it.

So now that I know that the project will be controlled by a Raspberry Pi, how will it actually look? What will the interface look like?

In general I decided that I’d use the standard guitar pedal format since it’s pretty ubiquitous and would fit in with the other pedals I use when playing.

ASIDE: For the uninitiated, when I talk about a “(guitar) pedal” think of a small box (usually metal) that has various dials, LEDs and screens on the top along with one or more footswitches that change the input signal. A great example is the DigiTech Drop, which drops the tuning of your guitar digitally when you press the switch and is one of my favourite pedals!

When I first started thinking about this project a few months ago, the first design that popped into my head looked like this:

What in the world is that? It really didn’t take me too long to scrap this particular design since it’s just baaad; why do I need an external screen? I think originally I was considering using a touchscreen to display the currently playing sound and to change settings, but it’s far too complex and unnecessary since a given sound is usually pretty short-lived and really I don’t want a lot of options to mess around with. Also, dragging that around to gigs would be an absolute pain.

In the end the only part I kept from this was the idea of a pedal with a series of buttons on it, with each button playing a different sound. That pretty much explains why design two was pretty much exactly that; design one without the screen!

What a beautiful marvel of design, this box ol’ box of buttons. I even increased the number of buttons up to six because more was apparently better at this stage. While this is theoretically functional, the button layout seemed a bit impractical; trying to hit the upper row of switches with a shoe would be pretty impractical for anyone regardless of foot size and the chance of hitting multiple buttons would be pretty high.

As such, I decided to move to a design that had the buttons in a horizontal line. To make sure the pedal wasn’t going to end up looking like a weird, disproportionate stick I decided to reduce the number of buttons back down to four, simply because I didn’t expect to need that many different clips in a given song and I wanted to avoid going too over the top.

This was also the point in my design that I talked to my friend and ever present sounding board, Mike Wade. Not only is he helpful at just sense-checking my designs in general, he has direct experience with audio/visual work considering he has been working the sounddesk at Shiloh Church most Sundays for the past ~13 years. One of the big questions he asked me was why I was trying to take an input signal and modify it, when it would be much easier to just output the sound separately? My logic was that I wanted to include this pedal in with the rest of my signal chain, but Mike made the point that on the mixing desk it’s far more practical to have the different signals coming in separately so that they can each be mixed and modified on their own. This definitely helped me simplify the build since I was not looking forward to converting the signal from a 1/4″ jack, figuring out how to splice in the additional audio and then converting it back to a 1/4″ jack again!

This design feels a lot better, but I’m feeling a distinct limitation: you can only select four different clips. How about we increase the number of buttons, but this time use them a bit more tactically?

One screen and a couple of buttons later, we’ve got a way of viewing and selecting banks (groups) of audio clips. The benefit of this approach is that I can associate each song with one bank and quickly switch between them without much effort.

I’m still trying to figure out an enclosure that I can use for this, since it’ll need to be quite large to fit all of the components inside while also being strong enough to stand up to being stepped on but easy enough to work with given the basic power tools I have available. At the moment I’m thinking a plastic project box would do the trick, although I’ve still got to consider what dimensions I need to support and whether it’ll be robust enough. That discussion will come in a post later in the series!

Phases

With any project it’s worth figuring out what the MVP (minimum viable product) is and aim for that first. That way, you get straight to something usable with the least amount of effort and after that you can continue to work in phases where the end result of each is also distinctly usable. This helps motivate you by giving you concrete goals to work towards and achieve progressively, rather than aiming right for the end result and having it in various stages of broken until you’re finally done and it all (theoretically) comes together at the last second.

On this project, I’m going to work in three phases for the build:

1. Pure software implementation
2. A breadboard implementation of the hardware connected to the software built in phase 1
3. An upgraded version of phase 2, placed in a proper housing and using permanent components

The reason for this approach is that while this is a project with both software and hardware elements, I’m not particularly experienced with electronics components. As such, having phase one be entirely software means that I can sort out most of the logic using what I’m most comfortable with and in a way that I can get easy feedback and quickly iterate on. As well as that, getting the logic sorted will potentially direct my approach in the following phases.

Next Steps

So now I’ve got a general plan that includes what will power the logic/processing, how it will look and be used along with a general idea of how I’m going to execute the project and the different phases. So what’s next? Two main things:

1. Start working on phase one (software implementation)

Where better to start than… at the start? Without the logic implementation the hardware part isn’t particularly useful to me, so I’m going to put together the basic code to load and play the sounds along with a test interface or two that I can use to mimic the hardware buttons I’ll add in phase two.

2. Start preparing for phase two/three by purchasing some electronics and other hardware

Although I’m trying to approach these phases one at a time, ordering and receiving stuff online can take a while so I’m trying to work on the different phases concurrently to make sure that there aren’t any major periods of waiting around.

---

This is the first post in a series on the creation of SoundFloored; check out the second post, where I talk about the software I wrote to power the project!