[sdiy]

[Byron G. Jacquot]

>Presently my device allows turning off Running Status on the MIDI OUT port
>but the occasional sending of full status may make some sense.  I couldn't
>imagine sending it 10 times a second as i find MIDI easily congested as it
>is, but perhaps once every 10 seconds or as the 1st message sent after a 10
>second lull in MIDI Voice message may be a good idea.

The problem might be that it's more hassle to set up a 10 second timer to
use for this.  A compromise might be to count the number of messages sent
under a given running status byte, and retransmit the status byte every 10
or 50 or 100 messages.

I've found that I send other types of information (mono pressure, continuous
controllers) often enough that running status isn't an issue.

I've seen some other uses of MIDI with devices that would use too much
running status, and then one dropped byte would lead to lots of invalid
information (say confusing your note number with your velocity).  But
inserting one status byte every 50 messages would only use about 1% of your
bandwidth, and guarantee you never lose more than 50 messages...of course,
if your receiver thinks you want to turn on notes 0 and 127 50 times in a
row, you might have problems!

>I have never personally had any problem using running status on the MIDI OUT
>with a variety of synths (PC and standalone).  I would be disappointed to
>hear that folks are finding their synths getting confused considering how
>simple a MIDI exchange is and how well known it now is.

In my experience, most commercial synths do fairly well most of the time.
My old Prophet 600 would get confused easily, and my TR-909 will lose
synchronizaton if you repeatedly hit the stop/continue switch (too many or
too few clock bytes in there).  I can think of some boneheaded
implementations (things that only work on channel 1, or ones with "soft"
thru), but the receivers are usually good.

>The case i was considering was "flaky" cable where a message or two could be
>lost due to lack of continuity.

I think the problem isn't lost messages, but lost single bytes, because the
meaning of the bytes that do arrive can change significantly.

>This case would ultimately respond to a 10 sec full status period and
>quickly respond to the 10 per second but perhaps it would be better to
>switch to sending full status if you use flaky cabling.

It could always be a software option, turn it on if you get unexplained
behaviour.

Byron Jacquot