Re: Real-time category

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

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