[sdiy] MIDI specifications

[Rude 66]

paul and scott,

 you guys are great. i've been having these terribly midi hiccups in my
system and tried everything.. different soundcards, drivers, blah blah..
seemed only to get worse. tonight i soldered a small passive thrubox (1 in,
5 out) hooked it up not using the synths' thru's anymore. amazing
difference! even with a small test the same track now plays back totally
smooth. it's such an obvious thing i totally didn';t think about it..

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