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.

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

> 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

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/
>
>
>

--- In xl7@yahoogroups.com, "David DeciBel" <spec@s...> wrote:
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.
> 

   These days I don`t know about you guys but I have trouble thinking 
of a product that is perfect. The xx-7`s are fun boxes with good 
sounds and even with the imperfections I still love them. I think 
that eventually you just learn what you can and can`t do with a box 
anyways. Imperfections just give it character. Just my 2 cents.

   Peace in the middle east!

On 12/7/02 12:20 AM, "David DeciBel" <spec@...> wrote:

> 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?

Latency is time delay between when something is supposed to happen and
something actually does.

Latency is a problem in a number of ways.  if the latency is very long (>
20-30 milliseconds) the later sound events (like notes) will be perceived as
separate events and not part of the same one as it should have been.  So for
example a chord playing with one of the notes 50 milliseconds late will not
sound like the same chord as all the notes playing on time.  below around
20-30 milliseconds different psychoacoustics come into play which leads to
problem 2:

Flamming.  When one or more notes are played close together but not
precisely together they will sound like a single perceived event but the
phase-differences will cause the sound to change, sometimes dramatically.
(phase is nothing more than a way of stating a time difference between two
sounds at the same frequency).  Flamming can be an interesting effect in its
own right but one that you should choose to have occur and not the gear on
its own.  As the time difference (caused by the latency) becomes less and
less the sound will become less "flammed" and more like an enriched sound.
The classic example of this problem occurs in modern dance music production
where beat timing is critical between the drum hits.  layering drum sounds
to make them more powerful or interesting and then having one of the sounds
flam another is normally not a good thing.

So far these problems can actually be compensated for in a sequencer by
shifting the note (or other events) in time so that they line up correctly.
if the notes on track 2 are occurring too far behind track one you can slide
the timing of track two so that things happen earlier.  This type of timing
shift was a quite common procedure before the days of sample-accurate DAWs
with software instruments.

The real troublesome aspect of latency is not that you have it (you'd
probably be surprised at how much latency is actually flying around your
studio) but that it can be variable.  Something can be late one moment and
not late the next.  This type of latency is a form of timing jitter and it
is something to be avoided.  Timing jitter can not only change the way
something sounds but it can adversely affect the feel or "groove" of a
rhythm. Incidentally when people talk about the "tightness" of a sequencer
it is generally the jitter that they are perceiving, or lack thereof.  Lower
jitter implies "tighter".

Consistent latency that is predictable is manageable and actually expected
in these type of music machines we use.  MIDI itself is a contributor to
latency and the more dense the activity on a MIDI channel the higher the
change of having some events sometimes be late.  In this case the latency
will be variable since it depends on the amount of activity and is this not
good.  This is one reason that complex MIDI setups normally require
sequencers with multiple MIDI outputs.

How well a sequencer is implemented is also a big factor in the latency and
its variability.  This is why the tests on the XX-7 are less about how much
delay (latency) there is and really more how it varies under different
conditions.  This is also why sequencers based on OS's like Windows can be
so problematic and have "feel" problems.

Finally your sequencer is not the only contributor to this problem.  Sound
modules and other synthesizers all have internal latencies and depending on
how solid the design these can be inconsistent.


drk

www.delora.com/music
www.mp3.com/zdrk
drk.iuma.com

> 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.

Sure - and that was what I wanted to test. (Obviously, I had to set
all the other track volumes to zero prior to recording in order to get
a distinct recording of the test pattern.)

> 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).

Sorry - yes, I meant jitter.

> Also, it should be very "deterministic", meaning that the same notes
> each time will be delayed the same amount (or very close).

Yes, it did sound as if there was a pattern to the jitter, which I
assume was just determined by the quantity of (zero-volume) voices
being triggered on higher-priority tracks.

> 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.

Will do, definitely, although I tend not to use the XL as an external
sequencer (but only as an external MIDI clock).

This is a useful test case to throw at people who complain that "MIDI
is too slow" btw. - usually it's the response times of the devices
that are significant (and the XL-7 is doing a lot when it's triggered,
so it's not surprising). I'm curious: what is the nature of the
communication between the sequencer and the sound engine? Are there
real MIDI messages being passed around internally?

> 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.

OK - again, I guessed that that might be the case.

> The easy way to give the
> arpeggiator a head start is to slide the trigger notes back a tick or
> two in the sequencer.

I'm sure there's a slide data feature somewhere in the pattern editor,
but I'm looking through the manual PDF (and the LCD!) right now and
can't find it...

I don't know whether it's a feature request, but it would be nice to
have some kind of track offset parameter (in ticks?) that could be
applied to a track/pattern without actually altering the data (or the
data position) so that I could play my important 16-note track at
ticks=-1 to force it slightly ahead of the beat. (Otherwise, actually
shifting the events looks ugly in terms of the displayed timings, and
almost certainly screws up the grid/step editor.) I know Vision has
this feature; I don't know about Performer.

> Hope this clarifies stuff a bit!

Absolutely - thanks - and I hope I didn't come down as being too
critical on the machine. I really like using it, but something about
the timing was nagging at the back of my mind and I wanted to know
what it was. I'm more than happy with a 2msec response time so long as
I can achieve that where I need it.

-- 

  nick rothwell -- composition, systems, performance -- http://www.cassiel.com

I started thinking about these things today.  My question is this:  Midi is
a slow interface.  Why are we still using it?  Why doesn't someone come out
with MIDI 2?

hmmm

----- Original Message -----

From: <tekmunky@...>
To: <xl7@yahoogroups.com>
Sent: Saturday, December 07, 2002 12:14 AM
Subject: [xl7] Re: Sequencer timing: here comes the science


> --- In xl7@yahoogroups.com, "David DeciBel" <spec@s...> wrote:
> 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.
> >
>
>    These days I don`t know about you guys but I have trouble thinking
> of a product that is perfect. The xx-7`s are fun boxes with good
> sounds and even with the imperfections I still love them. I think
> that eventually you just learn what you can and can`t do with a box
> anyways. Imperfections just give it character. Just my 2 cents.
>
>    Peace in the middle east!
>
>
>
> 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/
>
>
>

On 12/7/02 7:09 PM, "David DeciBel" <spec@...> wrote:

> I started thinking about these things today.  My question is this:  Midi is
> a slow interface.  Why are we still using it?  Why doesn't someone come out
> with MIDI 2?
> 
> hmmm
> 
"MIDI 2" is already here!  Its just buried inside your computer sequencer
when it is using software instruments, or inside your hardware sequencer
like the XX-7 when it is "talking" to the internal sound engine.  In both
cases the speed of the MIDI interface does not enter into the equation
because the internal commands move at "the speed of software".

MIDI suffers two problems, one easy to fix, one less so.  The easy one is
its raw data rate.  31.5KBaud is really slow by today's standards.  And we
see the ill-effects when cramming too many simultaneous MIDI events down one
cable.

Unfortunately simply speeding up the interface will not necessarily improve
the performance and latency response of your MIDI devices.  Handling a
higher data-rate interface require additional and sometimes dedicated
communications processing power.  Even with that addition the internal OS's
in instruments still have to manage this along with all other internal
time-sensitive tasks.

Many current sound modules and synths are actually more at fault for latency
and timing variation then MIDI's data rate.  So additional improvements will
be needed throughout before you will see all the benefits.

Already Yamaha, Korg, Apple, and others are trying to position M-Lan as a
successor to MIDI.  This runs at 200Mb/s rates for audio and MIDI so it has
more than enough bandwidth.  To date this has been slow to be adopted,
primarily I believe because the extra complexity of the interface
significantly complicates the MIDI device design.

MIDI was originally successful because it was very cheap and easy to
implement within the current popular synthesizer technology.  They could
have made it better from the start but chose instead to make it attractive
to add, something the business guys wouldn't veto because of the added
product cost or delays in development.

Many have tried to get MIDI 2 off the ground and I attended meetings back in
87/88 where MIDI was discussed.  Market conditions more than anything are
preventing it.

Finally, as an aside, I believe the true problem with MIDI is the logical
protocol and not the speed per say.  The protocol is heavily prejudiced
towards music which relies on discrete note events.  It lacks adequate
capabilities (without relying on non-standard escape mechanism) for true
fine control of multiple parameters in real-time on a continuous basis.
This makes its utility quite different from say the analog synthesizer
standard of voltage control.  MIDI is a wonder enabler for the industry and
has fundamentally changed the way we make music.  But it has also moved us
collectively into a far more narrow range of possibilities.  It is almost
tragic that software sequencers have failed to overcome this limitation now
that software instruments are a reality.


drk

www.delora.com/music
www.mp3.com/zdrk
drk.iuma.com

Screw Midi, screw M-lan...and while your at it, give internal ram the big
boot to the curb as well (smart media is the way to go). M-lan seems
acceptable since it can pipe audio in full stream as well, but so can
firewire...it's already become the premiere methodology for video
transferring, at least in the consumer to semi-pro market...it should have
become the prime method for multi trakc recording as well...why not
integrate midi too? USB was only eaten up by consumers over firewire becasue
it was pushed harder, but its by far not up to par comparitively.

Of course, none of this will actually happen, the weaker path always seems
to be taken through to the mainstream in the computer world...pc's over
mac's, usb over firewire, proprietary money grubbing OS producers over free
open source faster products (linux? or even BeOS?), MPG2 over MPG4 for the
digital video standard, MP3 over WMA...ouch....come on.

ByronIV
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002

mlan is firewire.

----- Original Message -----
From: "ByronIV" <byron@...>
To: <xl7@yahoogroups.com>
Sent: Sunday, December 08, 2002 2:52 AM
Subject: RE: [xl7] Re: Sequencer timing: here comes the science


> Screw Midi, screw M-lan...and while your at it, give internal ram the big
> boot to the curb as well (smart media is the way to go). M-lan seems
> acceptable since it can pipe audio in full stream as well, but so can
> firewire...it's already become the premiere methodology for video
> transferring, at least in the consumer to semi-pro market...it should have
> become the prime method for multi trakc recording as well...why not
> integrate midi too? USB was only eaten up by consumers over firewire
becasue
> it was pushed harder, but its by far not up to par comparitively.
>
> Of course, none of this will actually happen, the weaker path always seems
> to be taken through to the mainstream in the computer world...pc's over
> mac's, usb over firewire, proprietary money grubbing OS producers over
free

> open source faster products (linux? or even BeOS?), MPG2 over MPG4 for the
> digital video standard, MP3 over WMA...ouch....come on.
>
> ByronIV
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002
>
>
> 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/
>
>

it is??? Well, just screw me then! I was in a bit of a drunken stupor last
night when I wrote that...forgive my ranting :b

ByronIV

> -----Original Message-----
> From: Ravi Ivan Sharma [mailto:noision1@...]
> Sent: Sunday, December 08, 2002 11:47 AM
> To: xl7@yahoogroups.com
> Subject: Re: [xl7] Re: Sequencer timing: here comes the science
>
>
> mlan is firewire.
>
> ----- Original Message -----
> From: "ByronIV" <byron@...>
> To: <xl7@yahoogroups.com>
> Sent: Sunday, December 08, 2002 2:52 AM
> Subject: RE: [xl7] Re: Sequencer timing: here comes the science
>
>
> > Screw Midi, screw M-lan...and while your at it, give internal
> ram the big
> > boot to the curb as well (smart media is the way to go). M-lan seems
> > acceptable since it can pipe audio in full stream as well, but so can
> > firewire...it's already become the premiere methodology for video
> > transferring, at least in the consumer to semi-pro market...it
> should have
> > become the prime method for multi trakc recording as well...why not
> > integrate midi too? USB was only eaten up by consumers over firewire
> becasue
> > it was pushed harder, but its by far not up to par comparitively.
> >
> > Of course, none of this will actually happen, the weaker path
> always seems
> > to be taken through to the mainstream in the computer world...pc's over
> > mac's, usb over firewire, proprietary money grubbing OS producers over
> free
> > open source faster products (linux? or even BeOS?), MPG2 over
> MPG4 for the
> > digital video standard, MP3 over WMA...ouch....come on.
> >
> > ByronIV
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002
> >
> >
> > 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/
> >
> >
>
>
>
> 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/
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002

> MIDI was originally successful because it was very cheap and easy to
> implement within the current popular synthesizer technology.

...and STANDARDISED. The electronic instrument market was in serious
trouble in 1983, proprietary communication interfaces and all, and
MIDI, with its promise to make instruments from different
manufacturers talk to one another, was something of a
godsend. Musicians are generally conservative technology-wise, and
unwilling to adopt a new "standard" just for the sake of it,
especially if it comes from a small, niche company or one which might
well decide to switch its product line or marketing strategy. Who here
remembers Lone Wolf's MediaLAN? What about Peavey's SMDI? How would
you feel about having instruments with such interfaces sitting around,
useless, in your studio today?

> Finally, as an aside, I believe the true problem with MIDI is the logical
> protocol and not the speed per say.  The protocol is heavily prejudiced
> towards music which relies on discrete note events.

Absolutely. Given that, it's done surprisingly well, but I suspect
that companies would be reluctant to expose their IP in the guise of
an extended or more sophisticated standard.

> It is almost
> tragic that software sequencers have failed to overcome this limitation now
> that software instruments are a reality.

Well, yes, but bear in mind that MIDI is slow, simple and discrete
enough that the data can be edited pretty much directly. I don't know
that a richer, more expressive protocol would be equally amenable.

(I also have my own issues with software instruments - I'm not going
to be tied into a proprietary system any more than I need to. As it
is, my two choices of hardware product - Korg OasysPCI and Nord
Modular - are both suffering from discontinued software support, but
luckily they work without continuing bug-fixes or support.)

-- 

  nick rothwell -- composition, systems, performance -- http://www.cassiel.com

It's all about everyone wanting the rights to it, no one is willing to let 
another manufacturer design the "next new thing" without having a say in 
it.  I was hoping the yamaha's mLan would change all of this when I first 
read about it a couple of years ago, though it doesn't seem to be going 
that way sadly.

rEalm





"David DeciBel" <spec@...>
12/07/02 06:09 PM
Please respond to xl7

 
        To:     xl7@yahoogroups.com
        cc: 

        Subject:        Re: [xl7] Re: Sequencer timing: here comes the science


I started thinking about these things today.  My question is this:  Midi 
is
a slow interface.  Why are we still using it?  Why doesn't someone come 
out
with MIDI 2?

hmmm

----- Original Message -----
From: <tekmunky@...>
To: <xl7@yahoogroups.com>
Sent: Saturday, December 07, 2002 12:14 AM
Subject: [xl7] Re: Sequencer timing: here comes the science


> --- In xl7@yahoogroups.com, "David DeciBel" <spec@s...> wrote:
> 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.
> >
>
>    These days I don`t know about you guys but I have trouble thinking
> of a product that is perfect. The xx-7`s are fun boxes with good
> sounds and even with the imperfections I still love them. I think
> that eventually you just learn what you can and can`t do with a box
> anyways. Imperfections just give it character. Just my 2 cents.
>
>    Peace in the middle east!
>
>
>
> 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/
>
>
>


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/ 







[Non-text portions of this message have been removed]

Would be nice to have the option to slide whole Tracks forwards or 
backwards by ticks :)

rEalm




The easy way to give the arpeggiator a head start is to slide the trigger 
notes back a tick or two in the sequencer.




[Non-text portions of this message have been removed]

IF you mean perfect as in features, then yes you're right.  If you mean 
perfect as in bug-free, then I think there's plenty of gear out there that 
meet that requirement.  Ummm, my ER-1 has never ever so much as hiccuped, 
that's one that comes to mind.

rEalm




   These days I don`t know about you guys but I have trouble thinking 
of a product that is perfect. The xx-7`s are fun boxes with good 
sounds and even with the imperfections I still love them. I think 
that eventually you just learn what you can and can`t do with a box 
anyways. Imperfections just give it character. Just my 2 cents.

 


[Non-text portions of this message have been removed]

http://www.giles.com/yamaha1/pressreleases/ProAudio/mLan.htm


--- In xl7@yahoogroups.com, "ByronIV" <byron@l...> wrote:
> Screw Midi, screw M-lan...and while your at it, give internal ram 
the big
> boot to the curb as well (smart media is the way to go). M-lan seems
> acceptable since it can pipe audio in full stream as well, but so 
can
> firewire...it's already become the premiere methodology for video
> transferring, at least in the consumer to semi-pro market...it 
should have
> become the prime method for multi trakc recording as well...why not
> integrate midi too? USB was only eaten up by consumers over 
firewire becasue
> it was pushed harder, but its by far not up to par comparitively.
> 
> Of course, none of this will actually happen, the weaker path 
always seems
> to be taken through to the mainstream in the computer world...pc's 
over
> mac's, usb over firewire, proprietary money grubbing OS producers 
over free
> open source faster products (linux? or even BeOS?), MPG2 over MPG4 
for the

> digital video standard, MP3 over WMA...ouch....come on.
> 
> ByronIV
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.406 / Virus Database: 229 - Release Date: 10/21/2002

Would be nice to have the option to slide whole Tracks forwards or
backwards by ticks :)

rEalm




The easy way to give the arpeggiator a head start is to slide the trigger
notes back a tick or two in the sequencer.

--- In xl7@yahoogroups.com, Aaron Eppolito <synthesis77@y...> wrote:
> > 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

I hate to be like my management, but...:  the science is interesting, 
but is there a fix??

zsk

Would be nice to have the option to slide whole Tracks forwards or
backwards by ticks :)

rEalm




The easy way to give the arpeggiator a head start is to slide the trigger
notes back a tick or two in the sequencer.

In a message dated 12/10/02 3:43:28 AM Eastern Standard Time, 
erik_magrini@... writes:

> IF you mean perfect as in features, then yes you're right.  If you mean 
> perfect as in bug-free, then I think there's plenty of gear out there that 
> meet that requirement.  Ummm, my ER-1 has never ever so much as hiccuped, 
> that's one that comes to mind.
> 
> rEalm
> 

hey bro..how do u have the ER-1 synced to the xl-7?  curious? looking to do 
some new daisy chains and have a couple of korg boxes laying around.  thanks 
in advance.

plastic


[Non-text portions of this message have been removed]

Yeah, too bad we didn't think of that for the 2.0 release... =)

-Aaron (with toungue firmly implanted in cheek)

--- erik_magrini@... wrote:
> > Would be nice to have the option to slide whole Tracks
> > forwards or backwards by ticks :)
>
> The easy way to give the arpeggiator a head start is to slide
> the trigger notes back a tick or two in the sequencer.


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

Yup, too bad. 
I have the feeling OS/2 will suck big time. :-P

Aaron Eppolito wrote:
> Yeah, too bad we didn't think of that for the 2.0 release... =)
> 
> -Aaron (with toungue firmly implanted in cheek)
-- 
Sebastien,
-=-=-=-=-=
When money talks there are few interruptions.
 
mailto:poumtschak@... -=- ICQ# 6030405
http://poumtschak.free.fr/ (a few Mp3 in bulk...)
http://www.mp3.com/unpretentious

I agree that would be great.

> 
> Would be nice to have the option to slide whole Tracks forwards or
> backwards by ticks :)
> 
> rEalm

Interesting, thanks for the info