I was digging in and got along before I saw the above snippet.
There are only four references to the variable switchState.
You read the switchPIN into it, then immediately compare by reading the switch again.
Usually, the previous switch state is saved to compare with a new reading. This would requite the the switchState endure, so it must be a global variable or a local variable qualified as static.
I would be re-writing the sketch at this point. So I recommend that you think it out a bit.
You need to do debouncing and state change detection to develop the information that a switch has become high or low (not is high or low), and maintain a state variable that can tell you if the switch is stable and high or low.
You may benefit from using the IPO model.
Input - read all the switches and pots and whatever.
Process - decide based on the inputs and any mode selected and current progress in executing that mode (including timers) what the output should become (or remain)
Output - actually write to the outputs
Input and Output are the only code sections that use digitalWrite(), digitalRead() and analogRead().
Input also sees if any timers in progress are done.
Process deals strictly with the logic - what should the output be, is it necessary to restart any timers.
I like my state change detection as much as everyone likes her own, so try this in the simulation that is linked on the post on the thread where I threw in my version:
HTH
a7