[sdiy] MIDI specifications

[Scott Gravenhorst]

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.

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/