Gear Debugging / Problem Solving

Band is all set up, seconds away from the opening chord, and you realize.. nothing coming out of your amp. Something is broken, and sh*t is about the hit the fan. People in the crowd starring at you, waiting for something awesome. You let your band mates know that something is wrong. The awkward silence of the band trying to figure out what’s happening. One of the worst feelings ever. I’m sure some of you have experienced something like this in the past. Now, it’s your turn to identify the problem, fix the problem and get back to the show. What to do?

Before getting into this, I want to talk about my background. I program for a living, and also work on networking and systems administrations on servers. Basically, I problem solve and debug all day long. Code and computers things go wrong almost all the time, and it usually due to user/code error, but similar to the band situation, a solution needs to be discovered quickly. Downtime and programming time is costly, and the time is money as they say.

The principles I use in the computer world for debugging and problem solving I apply to almost all problem solving situation, including gear. Some of these principles could be beneficial to you as well. So let’s get started.

Start with what you know vs. what you don’t know.

What does this mean? Frankly when things go wrong, you try to grasp the possibilities of what could be causing the problem. Depending on the situation, these possibilities can be massive. In fact, the possibilities of ‘bad’ outnumbers the ‘good’. So when you realize you have no signal coming out of the amp from the guitar, to cables, to pedals, possibilities could be everything in that run of the signal. Hundreds of possible issues from electronic failure, to power, to tubes, to whatever. This is what causes the ‘death spiral’ of thinking, and leads to analysis paralysis. You basically shrug you shoulders, strum your stings.. and think.. “I don’t know.. just no sound”. Start with what you know is proving what works, and quickly identifies ‘sections’ of failure. Does your guitar work? Prove it. Plug straight into the amp. Does it work.. yes. You *know* the guitar works, you “know” the amp works and you “know” the cable works. What does that leave? Refine your process, and identify more things that you know. Knowing, also means “knowing” something is broken too. With this philosophy, you’re segmenting quickly.

I think about this often while debugging pedal circuits as well!

Start from inside to out.

I use this when I work on networking problems usually. I’ll do a quick example. You turn on your computer, you go to Google, and you get “Network timed out” or “page is not available”. My parents would call the Internet Service Provider to see what the issue is. They would walk through a bunch of test, wasting hours, that’s when you realize the network plug or wireless adapter is off on the computer. Starting from inside to out, means look at the closest things from the point of failure before going way out, and say the “internet” is broken.

Starting from inside to out with guitars, I look at the source of the sound first. That would be guitar. You know, the thing that you’re directly touching. That’s pretty close. Does the guitar work? Yes.. okay, moving further out.. go pedal to pedal. This would involve plugging direct to the amp, or bypassing the pedals directly to the amp. I’ve seen when people aren’t getting signal jump right to the amp. That’s outside.. there are a lot of things before the amp to focus on.

Know your options.

When I work on programming obstacles, I don’t want to waste too much time focusing on the main problem. AKA – banging your head against the wall. There is a point, where you need to move on to get things rolling NOW, and we can address the issue down the road. While you’re problem solving, you need to also think about the ‘worst case solution’. If you need to bypass the pedals, then that’s what you need to do, but think of these plans WHILE you’re figuring stuff out, so when it’s time to make a decision to get the show rolling, you can jump to that solution quickly. That could be borrowing and amp or guitar, play with straight signal, or removing/bypassing a bad pedal or patch/instrument cable.

Don’t make changes prior to a show.

This isn’t a problem solving, but a pro-active principle. In programming, there are some terms – “hose and go” and/or “trash and dash”. This means making a big change to code, then leaving for the afternoon, without thoroughly testing prior to promoting that code. Now, stuff is broken and the programmer is gone, and nightmare begins.

Always do changes to your board, amp, guitar, gear before rehearsals – never before a show. I know you just got that new pedal and you want to debut it for tonight’s show, but you could be introducing new variables if things don’t work properly. Is the pedal messed up? Are you drawing too much power now? Did you add new patch cables that are causing problems, etc. Don’t make your job harder on gig night.. make it easier.

So these are all easy, basic, but I’m always amazed watching bands that run into problems and have the old “deer in the headlights” look with no understanding on how to attack this problem. You just want it to work, compounded with being on stage, things can get overwhelming. Maybe some these principles can be useful to some of you.

Let me know what you think by commenting below.