Path: utzoo!utgpu!cunews!cognos!dgbt!gandalf!csulliva From: csulliva@gandalf.UUCP (Chris Sullivan) Newsgroups: comp.music Subject: MIDI and ISDN Message-ID: <2836@gandalf.UUCP> Date: 23 Oct 90 18:17:29 GMT Lines: 121 rlw@ttardis.UUCP (Ron Wilson @ Gallifrey) wrote: > In article <2707b24b.3dd1@petunia.CalPoly.EDU>, sseidman@polyslo.CalPoly.EDU > (The MIDIman) writes: > >I am writing a paper about communications this quarter, and I have chosen > >to talk about the MIDI protocol. My teacher has refined it a bit to cover > >new topics he hasn't received before. Sooooo, does anyone have any info on > >how MIDI and ISDN may someday work together? How does ISDN accomodate MIDI? > >How closely does MIDI fit into ISDN? What needs to be done to change MIDI > >to fit ISDN? Any articles, magazines, people, or even speculation will be > >welcome. Thanks. > > Please excuse the technical language - I will try to explain as cleary as I > can. > > The MIDI standard is a 2 layer specifation: The physical transmission, and the > data protocol itself. > > As far as ISDN, OSI, TCP/IP, SNA, and other communication protocols suites are > concerned, the MIDI data protocol is "just another application protocol" - ie, > ISDN et al will treat the MIDI messages as data. As such, MIDI messages can > be presented as data to ANY communication protocol at the sending end, and > will be delivered to the receiver as MIDI data. > > Examples: > > 1. Two programs could send MIDI data to each other via ISDN or other data com > protocol and not even be "aware" that they are using this other protocol. > > 2. Two MIDI devices could talk to each other other an ISDN or other network > by means of MIDI<->Network servers. > > 3. A program could talk to a MIDI device in a like manner. > > In short, a communications server program (which could be running in a > computer > or in a dedicated "box" (similar to dedicated sequencers like the MC-500)) > would provide a "front end" that acts like a MIDI interface - ie: it accepts > data bytes from the program or "real" MIDI interface, and delivers data bytes > to the program or "real" MIDI interface. The communications servers are > responsible for the details of the network protocols - nothing need be done > to the MIDI data protocol. Actually, it's a bit more complicated than that. MIDI uses 30-some-odd Kbps async (or start-stop for you X.25ers) frames, which don't go naturally into the 64Kbps synchronous clear B channels provided by ISDN. The channels have synchronization information for byte-alignment associated with them. So the trick is to get the bits from the async frames into the ISDN bytes. There are various ways of doing this: - sampled async, which will not work with MIDI due to the sampling rate being too low (64k) with respect to the MIDI bit rate (30+k). Works with existing equipment at the physical layer (up to 19.2K or so). - software-based rate adaption, where the async bits are placed in specific locations in the 64k stream. See V.110. Works with existing equipment at the physical layer. - taking your MIDI data and ignoring the async aspects of the spec, and as described by Mr. Wilson, above, just using the ISDN as a clear pipe. That way you get the full advantage of 8K bytes/sec. Must be done above the physical layer. The problem is you have to have the same special equipment and software at both ends, and can't just plug existing MIDI equipment into ISDN direct. Existing ISDN physical layer terminal adapters don't work at MIDI rates, so the upshot is you will need a new kind of device, to work with existing MIDI equipment at the physical layer (or, if you have access to the MIDI data, above the physical layer). The other interesting part of ISDN is the signalling. You need to have some way of doing call set-up and tear-down, as this system is really a telephone network. So you have to pick up, dial, get talking, finish, and hang up. All this is done using the Q.931 protocol over the ISDN D channel. MIDI doesn't have any equivalent. You have to do the wiring by hand with MIDI, just like the old patch telephone boards. You will need some mapping between the different devices on a MIDI bus and their ISDN addresses (phone numbers). Your new device could do that for you too. Sounds like a kind of a MIDI bridge or router. Once you've done Q.931 and LAPD, it is easy enough to do V.120 rate adaption. This gives you some addressing capability over a single call. But the real question, Mr. MIDIman, is why? You going to hold ISDN tele- conference jam sessions or something? It's a pretty dumb way to go for MIDI unless you need long-distance, since there isn't much ISDN gear available to the consumer yet. And you will need better than 64k to carry HI-FI voice... You must not play fast and loose with standards, if you want to interwork with everybody, everywhere. You can't just bang anything you like on top of OSI transport. You can, but you can only talk to yourself that way. If you get your MIDI widget through ISO and/or CCITT, then you can interwork with others who adopt your standard. This involves international approval. It would likely also involve a rewrite of the MIDI spec. Then there's the intellectual property issue, too. Who owns MIDI? The same is true to some extent with TCP/IP, but the process is different, and very US-centric. What the TCP/IP folks would like you to do is submit MIDI to them for scrutiny, with a spec for running it on TCP or UDP. Only after the Internet moguls approve it is it recognized as a legitimate application. ISDN is a CCITT standard, and SNA is IBM's baby. See also comp.protocols, for interesting discussions. You might even start a comp.protocols.MIDI, or .ISDN, if there isn't one already. ...regards, Chris Chris Sullivan Tel: 613.723.6500 Systems Architecture Group Ext: 8253 Gandalf Data Limited Fax: 613.226.1717 130 Colonnade Rd. S. Telex: 053.4728 Nepean, Ontario chris@cannibal.gandalf.ca (134.22.80.33) Canada K2E 7M4 (Chris Sullivan @ the Hinternet)