Conference napalm::commusic_v1

    I heard somewhere there was a maximum number of devices that should
    be serialy connected. Unfortunately, I heard this *after* I had
    already connected a MIDI network with *12* devices connected in
    the 'prohibited' fashion. 7 synths, 2 drum machines, 2 sequencers
    and a MIDIverb.
    
    It worked with neither timing or delay malfunctions. Was it proper?
    I've no idea, but *I* wouldn't lose a minute's worth of sleep over
    your proposed topology.
    
    Edd

I don't see why there is a limit at all.  Each thru port acts as a buffer
(repeater) electrically, and so there should be no signal degradation 
as units are chained together.  The MIDI delay should be nil, since all 
the buffering is done electrically, with no microprocessor intercept.
The only delay is the buffering delay - NIL.

So does anyone know why there is a limit in the MIDI spec?

Todd.

RE < Note 1096.1 by JAWS::COTE "Throw me down the stairs my hat!" >

	Thanks, Edd.  It's good for me to know that it has been done.  It seems
to me that stores will only tell you you need another device ($$$).  I glanced
at a keyboard article just now and it seemed to imply that delays tend to happen
more when you're sending a lot of continuous controller info.  It also says
THRU boxes were principally designed to deal with earlier MIDI equipment that
ommitted the THRU port.  

	Is there is an issue of there being enough voltage to travel a long 
network route?

	Has anyone here ever *really* dealt with the infamous MIDI network
delay problem?

	Dan (realizing, of course, Edd and I may be the only ones here today...)

RE < Note 1096.2 by HPSTEK::RHODES >

	Todd, I think you answered one of my questions already - the idea
of midi signal degradation.  I didn't realize there was anything more than a
Y junction at the IN port.  Thanks,

>So does anyone know why there is a limit in the MIDI spec?

	So Jim Cooper can stay in business?

	Dan

    It seems like I read somewhere that timing delays are possible but
    not necessarily probable, and that signal slew is the main problem
    ie: your nice square 1's and 0's turn into a more triangular shape...
    
    dave

    Todd,
    
    Didn't you and I perform an experiment at my house one night that
    confirmed MIDI-delay?? Or did we attribute it to attack rate
    differences??? I was gettin' kinda foggy towards the end...
    
    Edd

	Here's a portion of a Keyboard Magazine article by Steve De Furia in
the Jan '86 MIDI special edition... (reprinted without permission)

	"Whenever the output of a MIDI source is routed simultaneously to more 
than one destination, it must be transferred via a THRU port.  The transfer is 
not simultaneous.  The length of the delay will vary depending on the hardware 
design of the port, but it tends to be about 3 ms.  If you must connect several 
instruments to one source, avoid daisy chaining.  Each instrument in the chain
adds its own delay to the MIDI signal, which can create a noticeable lag between
when you strike a key and when the last instrument in the chain begins playing
a note.  If you use a thru box, only a single delay is added, and it is the same
for all the instruments recieving their signals from the box.

	"Delays can also be caused by trying to send more messages than MIDI is
capable of sending in a given amount of time.  As I mentioned above, this is
virtually impossible for a single player [yeah, but I'm married and have a 
family 8^)] to do.  However, if you're using a multi-channel sequencer to 
control several polyphonic synthesizers at the same time, you can cause a 
digital log-jam.  The messages can only be sent out one at a time, and each
occupies a fixed amount of time, so some must be delayed longer than others."

	There's other stuff in the article regarding baud rate, actual times for
single MIDI messages, etc.

	What this basically means to me is that for the type of stuff I do, I 
think I can live with the amount of delay (which would amount to a max of, say,
15 ms?).  I dunno, is 15 ms a noticeable amount of time?

	Dan

    You are correct that the complaint about massive MIDI chains is
    end to end delay.  Attacks and bends especially get indistinct.
    
    15ms is the value of 64th note at 240 beats per minute, so it is
    just barely (almost) noticable on the scale of ``macro-timing'',
    and is definitely quite noticable on a micro-scale.
    
    I did a thing where I was trying to model a million piece orchestra,
    so I chained all my boxes together, rather than using a thru.
    It was quite effective, actually.  You know, a little slow to start,
    and a little slow to stop.
    
    If you are trying to be tight, however, this configuration should
    be avoided.
    
    Steph
    

    If I remember right the reason delay is so high on the thru ports
    is because MIDI drivers are all optoisolators and they spec'd slow
    ones...                                            
    
    To keep JCooper in business? I've often wondered if the writers
    of the midi spec didn't consider the "add on" business when they
    spec'd everything out....
    
    dave
    

    
    eek. Sorry guys. Heres the scoop:
    
    There is nowhere in the spec that says anything about midi
    chaining. 
    
    There is little reason to believe that you'd EVER reach 
    15ms delay. Why? The thru circuitry is driven directly FROM
    the midi-in opto reciever. There may be a few micro-seconds
    delay, but thats it. Why? Because the opto output rise and 
    fall times are midi specced to be in that range. And there
    is a gate delay thru the (typ.) driver. Gee. a coupla nano's.
    BFD. 
    
    The only typ of distortion caused is pulse width narrowing
    due to cumulative rise/fall times thru a chain of recievers/drivers.
    This can be detremental. But seems that we'd need many devices in
    the chain to cause some problem (I have 7 series connections without
    a problem.) How many to get to 15ms if each is say 2usec? 
    
    More than you can afford.
    

  
    No, no, no ... HERE's the scoop (and I qoute from the MIDI specs):
    
    (p. 1) Sharp PC-100 and HP 6N138 optoisolators have been found
    acceptable.  Other high-speed optoisolators may be satisfactory.
    Rise and fall times should be less than 2 microseconds.
    
    (p. 2) A MIDI THRU output may be provided if needed, which provides
    a direct copy of data coming in MIDI IN.  For very long chain lengths
    (more than three instruments), higher-speed optoisolators must be
    used to avoid additive rise/fall time errors which affect pulse
    width duty cycle.
    
    (p.18) When MIDI THRU information is obtained from the MIDI IN signal,
    transmission may not be performed correctly due to the delay time
    (caused by the response time of the opto-isolator) between the rising
    and falling edges of the square wave.  These timing errors will
    tend to add in the 'wrong direction' as more devices are joined
    between MIDI THRU and MIDI IN jacks.  The result is that, regardless
    of how high the circuit quality, there is a limit to the number
    of devices which can be 'chained' (series connected) in this fashion.

    
    To further add to MIDI delays, don't some instruments copy the data
    from to the THRU port in software?  That is, you've got 3 serial
    ports to deal with (in,out,thru)... and whenever the internal software
    in the synth sees something on IN it passes it onto thru.  That
    would DEFINITELY add to the delay times, but reduce the problem
    of signal degredation..
    ... or is this not done?  I would guess that MIDI "merge" and other
    types of boxes would definitely introduce delays due to processing
    time...
    
    /Mitch.
    

I agree with Ron.  A few microseconds per opto plus a few TTL gate delays
(maybe 20 ns) is inaudiable (30 ns, worst case.  Now, the MIDI cable 
adds some RC and slows down transitions in the optoisolator following 
the cable.  How much? I not sure.

Usually what is heard (and usually blamed on MIDI delay) is an instrument 
delay in its response to MIDI data.  Some of the older instruments
have to scan the keyboard, respond to MIDI messages, and run the front panel
with slow little microprocessors (the UART may be slow, too).  This will 
induce some audiable delay.  I think this is what we heard in your studio,
Edd.  As I recall, it was the JX that seemed to lag.

regarding the previous reply, I believe this is called MIDI echo.  This
has the same delay problems as the instrument delay and can thus cause
an audiable lag.

Todd.

    Does the MIDI spec call for reshaping ("squaring up") of the pulse
    edges as you pass through the IN-THRU connection?  If not, that
    could be the issue.  There're two aspects to the pass through delay:
    the latency, which is how long after you put something in that you
    get something out, and the rise time of the output.  Are the times
    spec'ed as 90% of logic high or something like that?  If the pulses
    don't stay square through multiple pass throughs they could get
    there fast but be virtually unrecognizable.
    
    But, if it works, who cares?
    
    len.
    

    re:-.1  Well, I don't have my specs handy right now.  But, when
    I scanned it about the MIDI THRU issue I looked for some other mention
    of hardware enhancement of the signal and found nothing.  I don't
    recall if there was mention of a 90% spec or thresholds.  One thing
    the spec soes do is allow anyone to make a better THRU port.  The
    suggested circuit (which everybody seems to use) is pretty much
    the minimum allowed to run up to 50' cords.  I would imagine that
    by using some kind of coaxial cable, better parts and by taking
    care to do some kind of load balancing there could be significant 
    improvements.  Then again, it would probably be cheaper and easier
    to build a THRU box.  Oh, well.
    
    Steve_whose_COMMUSIC_IV_submission_is_almost_ready_db!