Support |
Per Boysen wrote: > The big challenge in software looping is to get around the AD/DA > latency, IMHO. The only way to do that is to use a software that moves > every new loop layer recorded a bit forward in time, to compensate for > the latency of the computer hardware. No such live looping software > seems to be available today (please correct me if I'm wrong). Mobius does latency compensation as you describe. It was probably the single most difficult thing to implement because it impacts so many internal calculations besides just lining up overdubs. For example, when you receive a MIDI event that ends a recording, you can't end it immediately, you have to wait until all of the input buffers have been received, otherwise you'll chop off a little of the end of what the user thinks they recorded. At ASIO latencies, this is difficult to detect, but it's really obvious with large buffer sizes. Similarly, whenever you make an abrupt playback transition such as going into reverse or triggering a loop, you have to skip over a bit of the beginning of the next loop because the output buffers are already full of content from the previous loop and they still have to drain. This is especially important when you're synchronizing. It's easier when you're quantizing because we know ahead of time when the transition will occur and begin output buffering of the next loop before we actually get there (does that make any sense :-) I certainly can't claim to have all the bugs worked out, but it seems to work reasonably well. The one thing I haven't been able to get my head around is how to do continuous playback rate changes (speed up, slow down) and at the same time do latency compensation "correctly". I finally decided not to bother because if you're changing the playback rate then you're almost certainly out of sync with any external devices anyway. So the minute dealignment caused by incorrect latency compensation is impossible to hear. Sorry for all the techo-babble, but it's something I love to talk about :-) Jeff