{"id":701,"date":"2001-03-10T00:00:00","date_gmt":"2001-03-10T00:00:00","guid":{"rendered":"http:\/\/www.sweetwater.com\/sweetcare\/?p=701"},"modified":"2007-04-27T00:00:00","modified_gmt":"2007-04-27T00:00:00","slug":"basic-troubleshooting","status":"publish","type":"articles","link":"https:\/\/www.sweetwater.com\/sweetcare\/articles\/basic-troubleshooting\/","title":{"rendered":"Basic Troubleshooting"},"content":{"rendered":"

Today’s Tech Tip is not about a specific problem, but about how to approach problem solving. We get TONS of people writing in with very in depth questions about what is wrong with their systems. They spend hundreds of words telling us all the things happening and ask two dozen questions along the way, finishing with a plea for help. Rarely do they go into detail about the things they have tried to resolve the problem, or if they do, they’ve tried the wrong things. I’m talking about system type issues here: things like hums, ground loops, intermittent behavior of a system or components in it, clicks and pops in digital audio, sync problems, messed up file transfers with multiple samplers sharing a common SCSI bus, and all kinds of other things. They’re all tough problems and can have hundreds of causes, which among other things makes them hard to cover in inSync. I could ask a question to narrow it down, but the answer would lead to five more questions. That’s why we have Technical Support.The particularly tough ones are where you’ve got a lot of equipment connected together. You have created a complex machine that may not be exactly duplicated anywhere in the world. We should review basic troubleshooting skills. If you are troubleshooting a bad piece of audio equipment one technique is often to inject a good signal at various points and then check at various points to see where it changes from good to broken (assuming the equipment works at all). This is what they teach you in Technician School 101, and is similar in concept to troubleshooting a system. You have to find and verify what works before you can chase what is broken. This means you must strip your system down until the problem goes away and what’s left works fine. Sometimes this is best done by starting with a bare bones system and then adding components (variables) gradually until it stops working. You should always try to find some way to make the problem go away so you can make comparisons between a working and broken system. Once you’ve done careful work here you should at least be able to ascertain where the problem lies and probably what is causing it. If the answer or solution isn’t obvious at this point (it usually is) you are at least equipped with enough information to seek help and ask specific questions. And you should at least know who to call for help.<\/p>\n","protected":false},"featured_media":0,"template":"","categories":[],"tags":[],"storecat":[],"itemids":[],"manufacturers":[],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n