H. Tone is thin

I find the "pre" versions of the amps are a little "thinner" sounding than the "full" versions, and tend to use the "full" versions, even if I'm running my setup "live" (through an amp and guitar cab). They tend to have more bass and just sound a bit richer. (see "full vs. pre" section)

If that doesn't help, see I tried this and it doesn't sound good. You may have an unconventional setup, and you might want to try Studio/Direct output mode and cab+mic simulation, even though you're running through an amp and speakers.

For "direct" tones, I like to use the SM 57 on/off axis mic, but find this can leave the tone a little thin. I compensate mainly by boosting the bass and/or low mids with a parametric EQ effect (freq at 15-30%). If this creates too much "thump" or ultra-low bass, I will EQ that out with a Mid-Focus EQ effect. I find this works better than using a Dynamic mic, which already has lots of bass dialed in, but that's another option. See the mic selection.

I also developed a "dual cab" method to try get the best features of two cabs that excel at opposite sections of the frequency range. See Dual Cabs.

Top of Troubleshooting

I. Software Knobs move on their own

Wowsers! Did that knob just move itself?! Yes, this can happen. It is particularly troublesome when it happens with a volume knob. You can fix this by moving the knob back and forth many, many times, all the way from their min to max position and back. This seems to get the dust or whatever else that causes the knob to malfunction out of there.

Top of Troubleshooting

J. I'm Getting dsp Limit Reached Errors

To clear up a few misconceptions, the error isn't about how much DSP you are actually using but how much you could potentially be using, if you turned on every effect/amp in your chain and were using them in a manner that required the most processing power. Effects toggled off will count towards your DSP limit. A Pitch Glide effect currently set to no pitch change is calculated as taking up as much as one doing a 2 octave shift.

So each effect/amp is assigned a fixed DSP cost in the firmware. When you add anything into the signal chain, the Pod sums the DSP cost of everything in the chain, and if this will exceed the maximum DSP it believes it requires to maintain real-time processing it throws the error and removes the effect/amp from the chain.

The analogy would be if you were a factory worker assigned to place labels on bottles as they passed by you on a conveyer belt. The bottles are evenly spaced and the belt moves at a constant motion, but you have enough time to do your task for every bottle. If your boss tells you to start placing 3 independent labels on each bottle, now you can't keep up. You have to either knock some bottles of the belt or let them pass by without having labels applied. Same with the audio stream passing through the Pod. It would have to drop out audio or let some of pass through unprocessed to fulfill the processing demands placed upon it, so it doesn't let you tell it to do more than it can.

While overclocking the chips inside the Pod may make more DSP available, the software is not calculating available DSP versus what it assigned to do. It uses the DSP costs baked into the firmware. So unless you can write your own firmware, hacking your Pod won't do you any good here. Your only option is to make sacrifices.

See here for DSP allocation advice.

Top of Troubleshooting