A Basic Approach to Troubleshooting
Knowing how to approach determining and fixing a problem is an incredibly useful skill. Even if you don’t know the exact solution to every problem, knowing how to find that solution can save you a lot of time, money, and stress. There is a basic system IT people use when approaching troubleshooting that we can adapt to potentially increase your success rate in this niche field of music technology.
Before we begin, I would like to stress again the importance of knowing as much as you can about your system. It becomes much easier to identify and perhaps correct an issue if you know how your system works and have baselines for how it typically performs. Also, be sure to always make back ups of your data before attempting any trouble shooting measures.
The Computer Technology Industry Association (CompTIA) has laid out a series of eight steps that we can follow to troubleshoot our issues.
1. Identify the problem
The first thing we should do when troubleshooting is try to identify the specific issue at hand. At this step, we try to isolate a single issue that we are trying to resolve. If there are multiple issues focus on a single one, one at a time, until all have been successfully resolved. One issue may be causing others, so try to get to the root issue here if possible. So generally you want to start with the biggest issue, and see if you can pinpoint the exact problem at hand.
There are four likely areas we can consider here when looking for the issue. Typically any issue will fall within the following categories: a hardware issue, an operating system issue, an application issue, or a user-driven issue. By understanding the differences between each of these we can focus our skills to the one area that is needed, rather than exploring all potential resolutions for all potential problems at once.
For example: You have a template set up and you are attempting to record a midi track via an instrument library hosted on another machine with VE Pro. You can see on the midi track that midi data is being recorded and outputted to VEP, and you can see the level meter moving inside both the kontakt instance in VEP as well as the output routing in VEP itself. However, you do not hear any instrument inside your DAW. This is a template you’ve been using for a while so you know everything is routed properly. What could be the cause?
Well if we follow the flow of the signal from your MIDI track to VEP to kontakt and back to your DAW we see that everything works as it is supposed to up until the DAW. There is something in between VEP and the DAW that is causing audio to not pass through. In this instance, it may be as simple as the return track being muted or input monitoring being disabled, but do you see how the process of identifying the exact location of the issue could provide more insight than “it just magically doesn’t work”?
Some issues are quite common and likely has an easy explanation and fix. Check out the product’s manual for help, or specific internet forums that may be available. Your DAW likely has it’s own groups on facebook or even it’s own website, but also do a Google search on sites like VI-Control where composers post and discuss these topics often. If you are getting a specific error code with your issue, definitely use it during this research phase. You can also consider reaching out directly to the manufacturer, as many have help lines for customers established. Just be sure that you understand that even if you truly believe the issue is due to their product/software, it may not be and there may be nothing that they can do to help.
3. Establish a theory of probable cause
This step is where troubleshooting becomes similar to the scientific method. Here we come up with hypothesis and test each one to see how it affects the issue. Even if it doesn’t fix the issue, eliminating a potential cause gets us closer to determining the exact issue and finding the proper resolution.
4. Test the theory
After figuring out what could potentially be the issue, figure out a way to test it.
Going back to the set up described earlier, with a midi track in your DAW on one computer triggering a kontakt instrument hosted via VEP on another. Well what if the issue was kontakt was not being triggered. How could we isolate this problem?
Well, if both computers are working fine otherwise (especially in other VEP instances) we can pretty much rule out it being a hardware issue. This leaves it likely to be a software application issue. So how do we test this?
Does the kontakt instrument open and work properly inside the DAW hosted locally on the primary machine? Are other midi tracks working to enable different instruments inside the same VEP instance on the secondary machine? Never be afraid to test out the obvious during this phase. You want to eliminate as many potential issues as possible in order to get closer to the “correct” one.
Some common approaches you may want to test are:
· Is it plugged in & fully plugged in properly?
· Restarting the computer
· Check all of the routings are proper
· Make sure the tracks are not muted or solo’d
· Are the proper drivers installed?
· Is the software compatible with this OS?
· Are other computers able to perform the task?
· Does it affect this one program or all programs on the computer?
· Does it work in a different DAW or standalone?
· Can I get audio out via a separate app (such as YouTube)?
See how many of these ideas are very basic but can confirm and help you identify the problem by testing them?
5. Establish a plan of action
By this stage, we should have a general idea of whether or not this solved the issue. If it did, great! But more likely than not you may have to continue testing and tweaking until everything is corrected. ONLY MAKE ONE CHANGE AT A TIME. We want the system to be as controlled as possible, as we want to know what fixed the issue in case it comes up again in the future. By changing too many variables at once, you may also introduce new issues which we are trying to avoid.
Typically, we don’t want to test our theories on actual important data. So setting up “sandboxes” (in our case likely a dummy session of our template or a duplicated session of the projected) is a great practical way to see if changes worked without having to risk damage to the data at hand.
Step 6 only applies if we need to apply these changes across multiple devices. If you do, be sure to back up data on all of them before making changes and track the progress of the implementation if it is a more complex solution to make sure the process is fully completed across affected all computers.
7. Verify functionality
At this point, we want to double check the original problem and make sure that it has been resolved. Also be sure to double check that we didn’t cause additional errors in the process. If there are methods we can use to prevent this issue from happening in the future, this is the time to implement those as well.
8. Document the work
Many while troubleshooting often overlook this step but I consider it to be extremely important and urge all composers to keep a detailed log regarding their issue and solutions. This can be extremely helpful for you, your coworkers, or assistants down the line when the same or a similar issue arrives. You can use whatever format works best for you, but be sure to write down the problem, what you tried, and the solution that ultimately fixed it.
These 8 steps are just one approach to troubleshooting. There are many, but this is quite thorough and should provide a pretty solid framework for any troubleshooting you may need to do.