[sdiy] MIDI specifications

[Rude 66]

would this cause timing problems too? i've been working on a track with 2
solo parts that were a bit heavy on the controller-side in cubase, and it's
noticable that some devices are struggling to keep up, so to say. the
difference between, say, the midi clocked 909 and a midi synth arpeggiator
can be quite bad. and they're both at the end of the chain..

r./


----- Original Message -----
From: "Paul Maddox" <P.Maddox at signal.qinetiq.com>
To: <music.maker at gte.net>
Cc: <synth-diy at dropmix.xs4all.nl>
Sent: Thursday, April 17, 2003 4:53 PM
Subject: Re: [sdiy] MIDI specifications


> Scott,
>
> > Ah, so the better way to deliver a MIDI out to several devices is to use
a
> > MIDI thru box with one input driving many outputs as opposed to using
the
> > THRU on individual boxes in a daisy chain fashion.  Controllers are
> > problematic if they need to be downstream, these must be daisy chained
in
> > order to merge the data.
>
> Yes, by FAR!
> I now use an akai ME80P (midi patch bay, 10 outs) and the difference is
> quite astounding.
> Even if you just use 3 Midi Thrus you start being able to notice delays,
and
> on heavy bandwidth moments (forexample 2 channels of aftertouch data) you
do
> get note problems (some stuck, some missing)..
> I would never use MIDI ports unless I was really stuck, I would rather
build
> an extra MIDI through box than do this again.
>
>
> >
> > Gene Stopp <gene at ixiacom.com> wrote:
> > >One thing that is useful when thinking about these things in MIDI is
the
> > >true culprit behind the "minimize the MIDI thru connections" advice.
When
> > >the chain of MIDI thru connections consists of physical layer
repeaters,
> as
> > >shown in the MIDI spec for example, there will be cumulative bit
> distortion
> > >for each current-loop-to-logic-level-to-current-loop interface. If
enough
> > >thru connections are daisy-chained, the UART at the end won't be able
to
> > >frame the bytes properly and you'll get 16x sampling errors and
probable
> > >mis-interpretation of the commands. In other words, stuck notes. It's
not
> a
> > >delay thing, it's a distortion thing. Unless the MIDI device frames the
> > >bytes and re-transmits - this will regenerate the bit edges offering
> > >potentially infinite thru-chain hop counts, but now you will see delay
> > >issues since the process will be store-and-forward.
> > >
> > >Uh oh, I'm lapsing into work-speak.
> > >
> > >- Gene
> > >
> > >
> > >-----Original Message-----
> > >From: Magnus Danielson [mailto:cfmd at swipnet.se]
> > >Sent: Wednesday, April 16, 2003 6:02 PM
> > >To: gene at ixiacom.com
> > >Cc: synth-diy at dropmix.xs4all.nl
> > >Subject: Re: [sdiy] MIDI specifications
> > >
> > >
> > >From: Gene Stopp <gene at ixiacom.com>
> > >Subject: RE: [sdiy] MIDI specifications
> > >Date: Wed, 16 Apr 2003 17:15:27 -0700
> > >
> > >> Hey I remember that from my RS-232 datascope days...
> > >
> > >OOOoooo - when is that released? ;O)
> > >
> > >> Async data means there are no bits on the wire when there is no data
> being
> > >> sent.
> > >
> > >It actually doesn't mean that, but it has that effect in this case.
Being
> > >the
> > >nitpick I am here is a little side-track:
> > >
> > >Synchronous means that the information of a signal arrives in the same
> clock
> > >or rate as another signal.
> > >
> > >Isochronous means that the information of a signal arrives in the same
> clock
> > >or rate as other information on the same signal.
> > >
> > >Asynchronous means not synchronous, i.e. the information does not
arrive
> in
> > >a
> > >synchronised fashing in relation to some other signal.
> > >
> > >Anisochronous means not isochronous, i.e. the information does not
arrive
> in
> > >a
> > >synchronised fashing in relation to previously sent information of the
> > >signal.
> > >
> > >(Many confuses all this up, since an isochronous signal is often
> synchronous
> > >to the clock at the transmitting device, but if you don't have access
to
> > >that
> > >clock the property is meaningless and you can only speak of a
isochronous
> > >signal.)
> > >
> > >MIDI (and most of the time V.24/RS-232) is large-scale anisochronous
> (i.e.
> > >we
> > >don't know when the next byte comes) and small-scale isochronous (we do
> know
> > >when the next bit come within the transfer of a byte).
> > >
> > >For the lack of isochronism (or synchronism with some other signal) in
> MIDI
> > >(and other normal serial communication) causes the need to
> bit-synchronise
> > >to
> > >know when the bits comes in a transfered byte, and also when there is a
> > >transfered byte, since that is too unknown when it occurs.
> > >
> > >This need for synchronisation and identification of begining of byte
> calls
> > >for
> > >the start bit/stop bit scheme. You pay a price for not being
isochronous
> or
> > >synchronous.
> > >
> > >> Let's say the wire has two states, high and low, and when there is no
> > >> data it's high. The Start Bit is a low for one bit time. The next bit
> time
> > >> can be either high or low, and that bit is the first bit of the byte
> > >> (usually the one on the left if you write the byte 1001XXXX, for
> example).
> > >> The rest of the bits continue as either high or low, as expected. The
> > >first
> > >> bit time after the last bit of the byte must be high, and this is the
> Stop
> > >> Bit. Sometimes you will hear the term "Two Stop Bits", and what this
> > >really
> > >> means is that there is a minimum separation between the last bit of
the
> > >> previous byte and the start bit of the next byte of two bit times. In
> > >other
> > >> words, the Stop Bit is really part of the dead time between bytes
which
> > >can
> > >> be any amount of time, up to infinity.
> > >>
> > >> Since the Start Bit is required, and at least one Stop Bit is
required,
> > >> every byte on the wire is considered to occupy 10 bit times.
> > >
> > >Exactly.
> > >
> > >If memory serves me right non-transmission is logical high, start bit
is
> > >logical low and stop bit(s) is logical high.
> > >
> > >There are even such obscene things like 1,5 stop-bits.
> > >
> > >What seems unknown to some people is that UARTs actually make multiple
> > >samples
> > >of the bit and make majority decissions on the bit-value. Since you
> usually
> > >run
> > >at 16 times the bit-speed on the reference-clock, there is no problem
in
> > >placing
> > >3 or some other un-even number of samples. By summing them up an
> comparing
> > >to
> > >the limit the majority sample-count winns.
> > >
> > >Another interesting this is that you never really have synchronous
> clocks,
> > >but
> > >since a byte-transmission only lasts 10 bits or so, the synchronisation
> > >provided by the start-bit is sufficient so that bit synchronisation
isn't
> > >lost
> > >due to clock differances throughout the byte.
> > >
> > >HMPF! Why do I know more about this subject than I really think is
> > >necessary?
> > >Life is hard and serial ports is a mess.
> > >
> > >Cheers,
> > >Magnus
> > >
> >
> > =========================================================
> > - A smoking gun is one that's already been fired.
> > - That which gets rewarded, gets done.
> > - What good are laws that only lawyers understand?
> > - Government: The other religion.
> > - The media's credibility should always be questioned.
> >
> > "When you see a rattlesnake poised to strike, you do not
> > wait until he has struck before you crush him."
> >   -- FDR
> >
> > -- Scott Gravenhorst | LegoManiac / Lego Trains / RIS 1.5
> > -- Linux Rex         | RedWebMail by RedStarWare
> > -- FatMan: home1.gte.net/res0658s/FatMan/
> > -- NonFatMan: home1.gte.net/res0658s/electronics/
> >
> >
>