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

My question is this:  Are these signifigant problems?  I haven't had a
noticable problem yet.  But does that mean it's not there?  I don't know.

Latency is somthing that is there an electronics period, right?  What is
signifigant latency?

----- Original Message -----
From: "Nick Rothwell" <nick@...>
To: <xl7@yahoogroups.com>
Sent: Friday, December 06, 2002 4:12 PM
Subject: [xl7] Sequencer timing: here comes the science


> 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.
>
> The first set of drift timings are using a track pattern of 16th
> notes, running at 125bpm. There is *no* MIDI output - all tracks
> are set to "int". (oh: OS version 1.32.)
>
> * Empty pattern, apart from the test track: drift of around 2msec.
>
> * Factory pattern (Arctic Drift, in fact), tracks 1-15 muted, track
>   16 as test track: drift of around 3msec.
>
> * Factory pattern, tracks 1-15 running with volume=0, track 16 as
>   test track: drift routinely at 10msec, worst case around 24msec.
>
> * Factory pattern, test track on track 1, other tracks running with
>   volume=0: drift around 2msec.
>
> SUMMARY: best-case scenario has sequencer timing within 2msec, which
> is pretty hot. 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.) With lots of tracks running, the timing of
> high-numbered tracks is pretty dreadful, but low-numbered tracks are
> prioritised and tight. So: keep the timing-critical tracks near the
> top (top 6 if possible; from T8/T9 onwards the slop is audible).
>
> 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 only: drift < 2msec.
>
> * Test pattern as track 16, others muted: < 2msec.
>
> * Test pattern as track 16, others running volume=0: routinely 8msec,
>   often around 15msec.
>
> * 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.
>
> I've not done any timing tests of the internal clock-based modulation
> architecture; I guess that would be next. I can live with the
> sequencer timing since it's clear how to keep it tight; the
> degradation of the arpeggiator timing is worrying. (I've also had more
> serious problems with arpeggiator drift which I plan to track down.)
>
> 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.
>
> A note on the timing procedure: I just let the XL-7 freewheel,
> recording the test patterns into Digital Performer (also freewheeling,
> using a Korg OasysPCI as clock source). Each measurement is done with
> a single 30-second recording of the ticks displayed on two tracks, one
> of them offset by visual inspection by a whole number of
> 16th-notes. The drift can be seen visually by comparing events on the
> two tracks, and the sample offsets can be read off by inspection (and
> then divided by 44.1).
>
> Any comments?
>
> --
>
>   nick rothwell -- composition, systems, performance --
http://www.cassiel.com
>
> To unsubscribe from this group, send an email to:
> xl7-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>