Re: can u run multiple sooper loopers?

[Jeff Larson <Jeffrey.Larson@Sun.COM>]

Per Boysen wrote:
> When I tried that I found that the 
> timing is never recorded exactly  as I play it for the first loop round. 
> All following overdubs are  fine though, but the first loop is always 
> sucking. Probably because  of the latency involved in triggering with 
> the midi pedal

I'm going to hazard a guess that this is due to the lack of audio input
latency compensation.  A common error with MIDI controlled recording
software is to begin and end recording *immediately* after the MIDI
event is received.  This sounds correct, you want to handle that event
as quickly as possible to avoid "midi latency" right?  But actually
you don't.

The problem is that at any moment in time, the recording software
is receiving samples that were captured a short time in the past,
not what the musician is playing at that moment.  This is due
to the buffering inherent in all computer audio interfaces.  For
a typical ASIO block size of 256, this works out to a delay
of about 5.8 milliseconds.  So you must actually not begin
recording until 5.8 milliseconds *after* the receipt of the MIDI
event.

If you begin recording immediately the loop will include 5.8 milliseconds
of whatever "warmup" noise the musician was playing prior to pressing
the MIDI switch, similarly, if you end the recording immediately
it will truncate the last 5.8 milliseconds of what the musician thought
would be included in the loop.

Now, MIDI latency certainly is a concern and some people are able to 
detect it.
I experience on average 1ms of delay for each "thru" device between the
pedal and the computer, and then another millisecond to get it from the
interface hardware into the interrupt handler of the application.  So if 
you're
careful around 2ms.  Now it may take longer to get around to processing
this after it reaaches the interrupt handler, but once "inside the 
computer"
you can timestamp it with millisecond accuracy and compensate for it later.

What is interesting is that audio input latency is working to our advantage
here.  We always have to delay the processing of a MIDI event, and that 
MIDI
event may itself have been delayed.  But the audio latency is almost always
larger than MIDI latency, so you can compensate for it with:

     processing delay = audio latency - midi latency

Which in the above example with 5.8ms audio latency and 3ms midi latency,
we delay 2.8ms after receiving a MIDI event to begin/end recording.  The 
exact
amount of audio latency is easy to measure, MIDI latency is somewhat harder
but the software can give you a "knob" to let you tune it until it sounds 
right.

So, I believe there is no reason why properly written software cannot 
compensate
for MIDI latency during *recording*.  Triggering of loops for playback is a
completely different problem and I won't bore everyone with the details
(unless I'm asked :-).

Then there is the ever popular "jitter".  A MIDI event will not always
take exactly 3ms to get to the application, sometimes it may take 2,
sometimes 3.5 though rarely more than a 2ms variance unless you're
doing something stupid like defragmenting your hard disk or running
a weather simulator while you record.  I'm sure there are people
that can detect this.  I sure can't.

Jeff