Emu XL-7 & MP-7 User's Group

> In response to numerous comments about how tight the sequencer timing
> is on the XL/MP, here are some concrete timings. Executive summary:
> the timing accuracy varies from superb to unusable, depending on
> circumstances.

This looks an awful lot like the tests we did with a few storage scopes
and wave editors.  We did this a lot when we were trying to bring down
the pattern change time (the 1.11 release).

> * Factory pattern, tracks 1-15 running with volume=0, track 16 as
>   test track: drift routinely at 10msec, worst case around 24msec.

Even when the volume is 0, internal tracks (int or both) that are
unmuted still have to play the synthesizer.  This is in case the volume
is turned up while the notes would still be playing.  Therefore, you're
limited more by the synthesizer.  Note-ons take a finite amount of
time, depending on number of voices the note fires.

Note also that this is not "drift", it's "jitter".  Drift implies
cumulative error (i.e. after several minutes, drift adds up).  Jitter
implies non-cumulative error (i.e. several minutes later, it won't be
any worse than it was at the beginning).

Also, it should be very "deterministic", meaning that the same notes
each time will be delayed the same amount (or very close).  While this
doesn't sound like it matters so much on paper (or email?), it does
when you're listening to your pattern.  It means that if you're hearing
something that's sloppy, you can fix it; and conversely, if it sounds
good, it won't suddenly behave badly later.

Lastly, for a given note, higher numbered track performance will only
degrade if there are notes at that exact timestamp in earlier tracks. 
Translation: the track doesn't necessarily matter, just how many notes
are at the same timestamp on lower numbered tracks.  It is, however,
very good practice to put the most important things (timing-wise) on
early tracks.  Save those later tracks for pads, noises and other
instruments with longer attack times.

> Data in other tracks doesn't influence performance if the
> tracks are muted. (I have a feeling this wasn't true of
> OS 1.31, but could be wrong.)

That's correct, muted events take nearly no time at all.  This has been
that way, I believe, from the 1.00 release.

> Interestingly, turning MIDI on for the tracks ("ext"/"both")
> doesn't seem to make much difference. The XL-7 seems to have
> bandwidth/performance issues internally, regardless of the
> external MIDI traffic.

Right.  Turning the synth *OFF* however, will make large amounts of
difference.  Try setting all your tracks to ext (not both) except for
the test track and see how it fares.  This is a more accurate test of
the *sequencer* alone.  Also, you can do the inverse, play your test
sequence in from an external sequencer with all but the test track's
volume down.  You'll probably get similar results (possibly even worse
due to MIDI bandwidth) to your internal tests.

> A second set of timings tests the arpeggiator: this time, the
> sequence is four quarter-notes (300 ticks long), but the preset
> repeats at 1/16 notes.
> 
> * Test pattern as track 1, others running volume=0: routinely 8msec,
>   often around 15msec.
> 
> SUMMARY: in ideal circumstances (sparse data), the arpeggiator has
> slightly better timing than the sequencer, but it degrades equally
> badly when other tracks are active, and -- curiously -- lower-
> numbered tracks are apparently *NOT* prioritised, so there's no
> clear way of improving critical arpeggiator timing in a busy pattern.

The sequencer has priority over the arpeggiator.  If you've got other
notes firing (again regardless of volume) at a given instant, the ones
from the sequencer will happen first.  The easy way to give the
arpeggiator a head start is to slide the trigger notes back a tick or
two in the sequencer.

Hope this clarifies stuff a bit!

-Aaron


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com