Support
Looper's Delight
|
Support |
|
|
Gosh, it must be days since I've subjected everyone to a screed. Oh well, I'm in a festive holiday mood. > Looping happens to be a very time sensitive application, since users > constantly interact with it in a rhythmic fashion and timing inaccuracies > tend to get multiplied as the loop repeats. I don't understand this comment. You may have timing inaccuracies in the start or end points of the loop, or the edges of an overdub or SUSReplace. But once recorded the loop plays back in exactly the same way every time because of a lovely piece of hardware running a real-time OS (your sound card). The inaccuracies in effect become part of the "groove" of the cycle which may or may not be acceptable but I don't see how they can get worse as the loop repeats. If you're referring to techniques like dropping in a precisely timed SUSReplace on every repeat, then yes there is a chance that one or more of them won't be where they should and this may affect the groove of the cycle. But we're talking about milliseconds of variance, 2 or 3 not 10 or 20. Also note that this variance only affects the edges of the replace, not the tempo of what was played or its alignment with what was being heard when it was played. An argument I've seen raised a few times here is that humans can detect "jitter" in tempo down to about 1ms. This is true, but it doesn't really apply to human interaction with a looper. Timing inaccuracies once recorded will be played back exactly the same way every time, so they are not perceived as tempo jitter which is why I call them part of the groove. To be perceived as jitter you would have to be doing SUSReplaces very rapidly and evenly over an extended period of time, and I doubt there are many loopers with the timing or stamina to do that. > Also, there are often precise > synchronization requirements that need reliably exact timing. That is why > all dedicated looping hardware uses an RTOS. Many loopers like having > reliable timing, so this is an important issue to them. As I've said here before, synchronization is only a problem if you are synchronizing the computer with another piece of hardware. Synchronization among the tracks of a looping application, or between between tempo sensitive plugins running under a host application is essentially free and sample accurate. This is because there is only one master clock that drives all "devices", if there is jitter in this clock then all devices experience the jitter at exactly the same time, and all of this is hidden behind the latency introduced by the audio interface. There may still be timing inaccuracies in the processing of a MIDI command, but all devices will respond to the command at exactly the same time and remain in sync. Someone once asked me if I could make the tracks of an audio application drift gradually out of sync like several hardware devices freewheeling without a master clock. This is actually rather hard to do. Hardware is better at going *out* of sync :-) Synchronizing the computer with another piece of hardware is an entirely different matter. But if we're talking about MIDI clock sync the situation isn't so bad. At 120 BPM there is a MIDI clock every 20.83 milliseconds. This is an enormous amount of time and it is well within a non-real-time OS's ability to generate a reasonably stable clock at this resolution. Yes there will be some slight jitter, but all modern devices that slave to MIDI clocks perform "smoothing" of some form to effectively eliminate the effects of jitter. I challenge anyone to submit to a double blind experiment attempting to identify a drum machine freewheeling to its own internal clock and one slaved to a MIDI clock generated by Sonar or another modern DAW. There is one notable thing in the looping world that is impossible for a PC to do, and that is "brother sync" on the EDP, synchronizing two different hardware devices with sample accuracy. You can use MIDI sync and retrigger periodically but it isn't as good. Another point for RTOS. I've been giving this some thought recently, and something that may improve the situation is to connect PCs in a network using MIDI or a MIDI/ethernet bridge, then let the PC who defines the first cycle send a short sysex to the others telling them exactly how many samples are in the cycle, thereafter they synchronize using MIDI clocks. You will still need to retrigger periodically to keep them in sync, but since the loops all have exactly the same cycle length this will hopefully happen less often. You would not get the phase accuracy required for a stereo mix of the same signal, but for independent signals from different musicians it may be enough. I guess we'll just have to wait and see. Jeff