[sdiy] MIDI specifications

[Paul Maddox]

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