Looper's Delight Archive Top (Search)
Date Index
Thread Index
Author Index
Looper's Delight Home
Mailing List Info

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

RE: Sooperlooper or Mobius? Going back to software.




> Are you assuming that the latency of midi commands is zero?
> Otherwise is it correct to set
> Input latency compensation= audioIn latency=MidiIn latency
> Output latency compensation = audioOut latency + midiIn latency ?

Yes, to be really accurate you should factor in MIDI latency.
I think you meant this:

  Input latency compensation = audioIn latency - MidiIn latency

Subtract MIDI latency from input audio latency and add it to 
output audio latency.

Then if you want to be REALLY accurate, you should measure the
distance between your ears and your monitor speakers, calculate the
speed-o-sound delay and add that to your output 
latency compensation :-)

Personally I don't try to accurately compensate for MIDI latency
because it is relatively small, I just play around with compensation
numbers until it feels about right.

Accurately measuring MIDI latency is harder than measuring audio
latency.  I've read conflicting things but the general guideline seems
to be that each "hop" in a network of MIDI cables takes about 1ms.  So
if for example an FCB were plugged directly into a computer MIDI
interface start with 1ms latency.  If it was routed "thru" another
device connected to the MIDI interface start with 2ms, etc.

Next we have to measure how long it takes to get the MIDI message from
the MIDI interface device into the computer.  This is usually over a
USB connection.  I don't have the specs handy but I'm guessing this is
negligible.

Finally there is latency getting the MIDI message through the device
driver, OS, and finally to the application.  I've always thought this
was much less than audio latency but I've honestly never tried to
measure it.  

So if the FCB were plugged directly into a USB MIDI interface I would
estimate 1.5ms or 66 samples at 44.1K as a starting point and tune
from there.

I remember reading a web page awhile ago where a guy described a
process for accurately measuring MIDI latency.  He took a keyboard or
some other device that would emit sound with close to zero latency and
would also send a MIDI message.  I forget if he wrote a custom app or
just used a commercial sequencer, but the basic idea was to record the
audio and MIDI at the same time and compare the time of the leading
edge of the audio waveform with the eventual receipt of the MIDI
message.  Factoring out audio latency, this gives you accurate MIDI
latency.  I don't remember the number but I remember
thinking it was small enough not to bother trying to give people
a tool to measure it.

I suppose we could try something similar with footswitches: stick a
mic near the switch, digitally record the mic and the MIDI it sends.
The trick will be to locate the position in the recorded wave that
represents "full down" since there will be some swishy mechanical
noises as the switch travels down.  Sounds like a great project for a
rainy day! :-)

>  From my limited software looping experienceI think it's worth 
>   mentioning that when the player is monitoring 
>    through the pc (e.g. when using amp sim software ) that the 
>    easiest approach is to set the latency compensation to zero.
>    (with possibly a tweak somewhere to account for the lack 
>     of midi latency)

Yes.  When you monitor through the computer latency compensation needs
to be done differently since the player is doing part of it mentally.
I don't think Mobius does this correctly yet, I've been
meaning to revisit this for awhile now but it seems that most people
don't monitor through the computer.

Setting both input and output latency overrides to near zero is necessary
for overdub alignment, but strictly speaking I think there is still
be a need to compensate for MIDI latency.  The player may not always
adjust the timing of footswitch presses in the same way they adjust
instrument manipulation.  This could cause a situation where input
latency compensation needs to be NEGATIVE, which would require a short
"history" buffer.

Likewise when you start doing things like loop triggering with a
footswitch, output latency is still relevant.  So it feels like to be
pedantic about it we need more knobs.  Maybe two output latency
settings, one for overdub alignment and one for "jumps" in playback.
I honestly haven't thought this through yet.

Jeff