Recording Virtual Instruments with SampleRobot Part 6: Tips and Troubleshooting

This the sixth and final post in my series on sampling virtual instruments with SampleRobot. (Part 1 is here.) In this post I'm just going to list some troubleshooting tips and other observations that I couldn't fit into the other articles.

TROUBLESHOOTING POPS IN RECORDED SAMPLES

If the samples you record with SampleRobot end up having unexpected pops in them, that's a sign your computer was running out of sample buffer while recording. If you open up the samples in an editor like Audacity or WaveLab, you'll probably see something like this:

In both of these examples, you can see that the in the otherwise consistent and uniform waves in these samples, there's an abrupt glitch in the waveform, and this is where you hear a loud pop. What happened is that the sample buffer that was employed during the SampleRobot recording ran out of data, resulting in the loss of a small portion of the audio, similar to what would happen if you pressed pause twice while making a tape recording.

In my own work, I've only experienced this issue when using the virtual cable methods (and more often when using ASIO4ALL instead of just using VB-Cable directly). It could potentially happen when doing the analog interface-to-interface method, though. Here are some things to try when you run into this issue:

• The VB-Cable download package includes a control panel utility, even though the control panel is not actually installed on your system when you install the driver. When you extract the ZIP file that you downloaded from VB-Audio, you'll find the VBCABLE_ControlPanel.exe file inside. Just run it from the extracted folder.
  
  In the Options menu you can choose different "latency" settings (really you're just selecting a sample buffer size), and you can also adjust VB-Cable's internal sample rate. This sample rate is different from the input/output rates of program audio that you may be passing through the virtual cable. I'd recommend leaving both of these values at the maximum (7168 samples, 96000 Hz), although if you've tried all other tips below and you're still having problems you might try reducing the Internal SR (sample rate) setting to something closer to your recording rate. This will put less of a burden on your system and give you more mileage with the current sample buffer.
• Generally you also want to make sure that you've both been playing out of your instrument and recording in SampleRobot at the same sample rate and bit depth. Check your instrument/plugin host settings to make sure they sync up with what SampleRobot is expecting. Also, you may have noticed in my screenshot above that I had my VB-Cable set to 24-bit for input. This is due to a setting I made in the Sound control panel of Windows:
  
• If you are using ASIO4ALL, remember that sample buffers are device-specific. You have to actually have the specific device selected before adjusting the buffer size slider. With ASIO4ALL I find I pretty much always have to crank this up to the max:
  
• If you're using a standalone version of an instrument that also has a plugin version,  you might want to try using the plugin version of the instrument in VSTHost instead. VSTHost has the option to adjust its sample buffer, which might give you enough breathing room to avoid audio glitches. See Part 1 of this series for some more information on VSTHost.

  

  The VSTHost Wave Devices dialog has a sample buffer setting that many other hosts and standalone instruments don't have..

GETTING SAMPLE START AND STOP TIMES RIGHT

By default, SampleRobot auto-detects "note in" and "note out" times in your initial sample recordings so that when you export your sounds, they start right when an actual audible signal starts, and only run as long as the audible content plays. (In other words, SampleRobot may record an 8-second long recording of a 1-second drum hit, but when you export the sound with autodetection enabled, the exported sample will only contain that 1 second of audible audio.)

The default settings usually work just fine for the VB-Cable methods I described earlier, and for the Digital version of the interface-to-interface method, but I've found that sometimes it's not all that accurate when doing the Analog method, likely because of the tiny amount of noisefloor that's almost always present in analog recordings.

In the Multi-Sample RECORD Settings portion of SampleRobot, you will find the Thres.Prec.In and Thres.Prec.Out settings. These affect how sensitive SampleRobot is to the differences in the audio signal between silence and audible sound. If you find that SampleRobot isn't setting the sample start times properly in your exported sounds, try adjusting the Thres.Prec.In value to something lower than the default value of 0.90. If SampleRobot is ending your exported samples before the audible sound has finished (especially common on reverb tails), try adjusting the Thres.Prec.Out value with something lower than the default of 0.50.

Note that you have to change these settings BEFORE you record a multi-sample. So this means you might have to go through several passes of recordings as you experiment with different values. As you do this, it's REALLY important to remember that SampleRobot's default behavior is to skip any samples that have already been recorded. So remember to disable this option if you have to re-record some samples:

The Latency value in that window also has to do with auto-detection (it seems to have some relationship with note-out detection), but I'm told the default value of 21ms should be fine for most modern interfaces.

If the auto-detection simply isn't working out perfectly for you, you can always manually tweak the note-in/note-out points on a per-sample basis before exporting. On the virtual keyboard on the bottom of the SampleRobot window, right-click the sample you'd like to adjust. A little "E" will appear under that sample in the virtual keyboard, and your sample's waveform will appear in the Note/Loop/Release Editor. It's a tiny window, but you can zoom horizontally and vertically by right-dragging your mouse in the editor window, and you can pan the view backward and forward by left-dragging in the view. The N. IN and N. OUT sliders set the start and end points, respectively.

WRAP-UP

This marks the end of my biggest tutorial yet. Please let me know if you think I've missed something, or if you've got any tips of your own.