OVERRIDING MIDI pt.II (III?)

[Magnus Danielson]

Hiya!

I haven't followed the debate all that much, just read a few messages out of
this second round.... well, anyway:

I have been thinking of a replacement for MIDI of and on for years now, and
I have collected a number of thougths which migth be worth something for you.

First, I think that MIDI in it's present form has several deep disadvantages
and those would mean such a great constraint to an new system if it would be
directly backward compatible that the result would not represent the quantum
step of improvement necessary for people to become really interested.

Just boosting the speed or change connectors or maybe modify the protocol is
simply not enougth...

The weekness of MIDI of today can be noted in several ways, and here is some:

Speed
        The speed of MIDI (31250 baud = 3125 command words) is not by far up
        to todays demands with large patches and samples being sent down the
        line. Excess use of running controlers is know to cause bandwidth
        trouble in live preformance... and how any haven't fallen asleep while
        transfering samples over MIDI? :)

Connectors
        Really, the standard 5 pole DIN connector is not by far the ideal
        connector. They are not mechanical stable in their average apperance.
        They do also lack a decent lock method, something which is also
        important now that people have gotten the habit of jumping around the
        stage with their various MIDI controllers. Even in a studio situation
        would a more rugged and locked connector be intersting.

Topology
        If you only want to slave a number of sound generator from a controller
        (master keyboard or sequencer) will the MIDI approach be appropriate
        since it honours a strict tree topology (via splitters and midi-throug)
        with typhically only one feedback (which is the link which breaks the
        strict tree topology). Today is however the controler and generator
        doing much more interactive communication and this causes a trouble
        with which box has the feedback line. Except for multiple input
        interfaces, midi-mergers or plain old cable swaping I can't see any
        other way to do it as the standard is today...

Protocol & Parsing
        The current protocol has several drawbacks on different levels and
        among those I find that the strictness of the specs and the somewhat
        unclear parsing method is one know drawback. Also worth noting is the
        precuted selection on resolutions and channels etc... it leaves a lot
        to be desired.

Now, there is more to the drawbacks of old MIDI, but I thougth these where the
ones that could act as a lesson on what migth be done when doing a replacement.

Here's some thougths on what can be achieved on these topics:

Speed
        Today we can easilly set a twisted pair up to 100 Mbps without loosing
        bits or set the cables on fire... and there is chips around to do it.
        One could also settle for 10 Mbps just to be cheap...
        One way to get it up fast is just say "Ethernet" and accept all the
        (known) twists and tricks and sealoads of chips around for it.
        Ethernet has know troubles with to many transmitters and/or to active
        ones. This drawback could comes from the fact that Ethernet act as a
        shared medium of the CDMA/CD fame and there is not much fact that would
        say that the trafic shape of musical control data would make it much
        better... there is know cures for these problems and they are of the
        shelf products nowdays.

        A different approach is to go for a splitted medium where traffic is
        being sent on point-to-point lines and being switched in various ways.
        ATM *could* represent such a technology but there is other and
        possibly more interesting techniques to consider. A downside to this
        approach is that switches would be needed for all configurations
        larger than two boxes.

        My point is that there is several ways to go and much can be learned
        from watching the things learned in the network and telecom buisness
        over the years. A replacement of MIDI faces about the same trouble as
        the transmission of a video conference or a webpage from bigtits.com.

Connectors
        I personally like the XLR contact much for it is rugged enougth and
        will survive that I stand on it (by accident or in educational purpose)
        However, the 3 pin XLR migth just confuse things a little bit too
        much... why add yeat another signal among Mic, Mic with Phantom, Line
        Speaker etc. A 4 pin XLR is more uncommon but is still not unique...
        ah well. The RJ45's are kind of OK but is not that rugged that I'd like
        them to be... maybe one cannot make everyone happy with one contact but
        splitting into two types will cause trouble too... most manufactures
        will use the cheaper one (for obvious reasons) and professionals would
        like to have the more expensive one to keep their system stable...

Topology
        A dramatic break with todays topology is needed. A star topology should
        be possible with a hub. A shared medium *migth* be a way to go
        sometimes but migth not allways be great. A ring structure migth also
        have advantages.

        The shared medium strategy usually turns out to be cheapest but has the
        distinct disadvantage that everyone will hear everyone which will cause
        that every transmitter *migth* collide with any other transmitter.
        To avoid inrecoverble trashing of data is several strategies possible:
        Collision Detect
                Both senders detect collision and backs off for a (hopefully
                diffrent) random time.
        Collision Avoidance
                Transmitters actively avoids collisions by listening first and
                also have diffrent "death" times after the last packet on the
                medium (used in radio nets) to avoid collision further.
        Token Passing
                Transmitters pass the transmitt allowance token among them.
        Also notworthy is that shared medium is usually also restricted so that
        the boxes much be almost directly connected to the same wire... if some
        one breaks the wire at his box then will more boxes suffer... happends
        all the time with Cheapernet (cheap form of Ethernet using coax and
        T-connectors to all nodes).

        A ring topology also suffers the flaw that the system as a whole
        suffers when a line is broken. In a one-way ring is the suffering
        acute while in a two-way ring is it to some extent recoverable since
        there is an alternative way that trafic may take. There is however one
        advantage of ring networks that isolation of transmitters can be done
        quite effectively and collision avoidance is a simple task. With some
        tricks can bandwidth be reused quite effectively.

        A star topology has the advantage that a broken link will only affect
        those devices which talkes to the device with the broken link. This has
        a quite underestimated effect on the systems stability. In reallity is
        many office networks star topology these days... the downside is that
        a central isolating device (sometimes called hub) is needed.

        In reality is these techniques being used together to combine their
        various strengths. Shared medium and star topology is used in todays
        office lans with twisted pair cables on RJ45's connected to hubs which
        will electronically simulate the shared medium. Advanced hubs will
        even isolate transmitters as much possible. Ring and star topology is
        mixed in the FDDI rings connected to a FDDI concentrator which will
        be the FDDI equalent of a hub.

        There's many pros and cons in this buisness, but I thougth I would
        mention some of them.

Protocol
        Oh, what a chapter :)

        I think they key issue here is the ease of parseability and the
        strictness of the rules which governs it.

        One migth feel attracted to the idea of just go simple and pick the
        TCP/IP protocol suite (used on the Internet... I think you heard of
        it :) which will involve a known amount of CPU and memory load and
        also a know set of traps but also a know set of possibilities...
        One has to figure out the protocol that goes on top of TCP/IP anyway...
        Personally I think it is a little overkill for all devices to keep a
        minimal but still a TCP/IP stack... but why not?

        I think that it can be a good thing to give alternate routes for the
        same data to be transfered. One route would require the full parsing
        info but each such transmission would involve more processing in both
        ends. The other route would be a pre-allocated "channel" for which
        several things is being taken for granted once allocated.
        I beleive strongly that no single techinque will be *the* way to do it
        but rather that wise use of several techniques may create a much better
        result. I also see how some kind of various hardware support of channel
        isolation could be usefull (consider transmission on various continous
        fixed bandwidth channels could help over a fully shared bandwidth).

        The specs must give a strict description of a minimum system and also
        how that system is to be expanded into richer functionality.
        The specs must allow for future expansion in several various ways
        which also includes protocol revisions.
        The specs *should* (preferably must) specify for a unique way of
        remotely over the protocol determine the support of various features
        and the lack of those feature must be detectable.
        The specs *should* have some form of link state diagnosis power in them
        to aid the debugging of a link. This is a very simple tool really but
        solves many troubles in the telecom world.

Things like non-data (clocking) must also be considered... the system clock
to keep the system synchronised must be delivered within some limits in time.
The lower jitter and the lower various delays that can occur in the system the
more predictable (and possibly less irritating) will the system become.

I would vote for a stable house clock of decently high frequency (say a
megahertz or something *even*) distributed as part of the carier on a
synchronious system. Once you have a stable common clock in the system, what
would you not be able to do over the system?

I *strongly* beleive that such a new system *must* be an open standard with
no entry fee or royalty for the usage of it. There is an overbeleif in what
comersialisation will do for you... personally I have seen how such things tend
to fail commersially when people went for the open alternative... but then,
there is of course number of cases saying the other thing... this is my
personal view :)

This was written to give my view of things... and maybe add some new fuel into
debate... and hopefully some usefull info and ideas...

Cheers,
Magnus
would you not be able to do over the system?

I *strongly* beleive that such a new system *must* be an open standard with
no entry fee or royalty for the usage of it. There is an overbeleif in what
comersialisation will do for you... personally I have seen how such things tend
to fail commersially when people went for the open alternative... but then,
there is of course number of cases saying the other thing... this is my
personal view :)

This was written to give my view of things... and maybe add some new fuel into
debate... and hopefully some usefull info and ideas...

Cheers,
Magnus
PS. Sorry for repeating the last stuff.. I did a copy-n-fail over a slow line
and doesn't want to redo it... sorry!