Support
Looper's Delight
|
Support |
|
|
>> On 28 jun 2007, at 12.07, andy butler wrote: >>> afaik best possible for Windows is 3mS from in to out. >>> (+ AD/DA times) >>> ( though I don't know if anyone achieves that figure in harsh >>> reality) >> Generally you should be able to achieve lower buffer settings with >> good ASIO drivers on a Windows system compared to OS X, if both >> systems run on equal hardware. That's because OS X keeps some >> sort of safety margin. On 28 jun 2007, at 14.05, andy butler wrote: > thank you, > any figures to give an accurate idea of the difference. Sorry, I have no figures. I learned this in discussion with people that take interest in such technical details because they develop audio software and since I only have interest in this as a user I never memorized the exact details. But the figures for buffer handling should be easy to dig out from the OS X developer specifications. >> The next question would be why you need 6 ms rather than 12 ms? I >> honestly can't tell. > I can tell. What I meant was more like: If 12 ms delay sounds bad it doesn't sound less bad with 6 ms (hence my question "why prefer 6 over 12") ;-) >> Finally, all DAWs and the looping software Mobius (Windows XP) do >> proper compensation for any latency induced by the hardware. Every >> recording is shifted in time on playback to line up correctly in >> time. > > but beware, DAWs won't automatically compensate if you use an > external AD converter. > Mobius does not compensate for every function, no looping software > can. Correct! That's why I find Jeff's concept for Mobius so genius: You connect right output to left input and push a button, and it measures the analog output received from an analog input INCLUDING eventual extra AD converters, or other outboard gera you pass the signal through before it starts moving air. Then this measured (total) latency is used for time shifting of recordings. In the past we had a related problem in Logic because the busses were not part of the plug-in induced latency compensating system. This meant that if you set a bunch of audio channels to a bus, as a sub mix, they would all come out in the mix with the latency of the plug- ins applied to this particular sub mix bus. If critical for the mix, you could measure the latency of the plug-ins used on that bus and slap an extra "time-shift" plug-in on the bus where you keyed in the negative value to get the timing back on track again. Or you could simply move the tracks (pre bus/effect etc) manually in time to get the mix right. Today this is of course history ;-) > The trouble with latency is that it adds up. > 2 lots of "negligible latency", added together can > easy be significant. > If you're using speakers already, then the pc latency is more > noticeable. The software should compensate for all software induced latency and the rest is simple hardware latency, as in AD/DA. Such hardware induced latency doesn't vary so you should be able to measure it and rely on the figure. > 5) Are you already using a guitar>>midi converter, in which case > you already have > quite a bit of latency, and any more starts to hurt. It's natural to adjust your playing according to any given latency. However this MIDI guitar converter is a typical example of something you can never learn to compensate for, simply because it is not consistent (as "distance through air" or "AD/DA conversion") but varies for different notes. Greetings from Sweden Per Boysen www.boysen.se (Swedish) www.looproom.com (international)