Support |
At 10:41 AM -0700 8/15/98, Stephen P. Goodman wrote: >Michael Pycraft Hughes [mailto:pycraft@elec.gla.ac.uk] asked: > >> Out of interest, has anyone started working on a MIDI >> replacement based around FireWire? > >While we've been reading about FireWire for some years now, it hasn't >become >the broadly accepted process that we all hoped, perhaps because of the >unfortunate practice of what I call "Beta-ism"; it's not like FireWire's >been licensed to too many vendors, nor have tech specs been released to >the >general public so that They can make devices that use it too. huh????? firewire is a publicly available standard, IEEE1394. You don't need to license anything to use it. Several vendors have firewire nearly fully integrated in ICs. TI, for example, has numerous different firewire parts, I think including a single chip solution that connects directly to a PCI bus. It's quite easy to implement, and getting much cheaper. The reason it's not everywhere is just simple economics, the demand hasn't been great enough to bring prices down to where it's appropriate for low-cost PC's and consumer devices. It's getting pretty close now though. Microsoft will be including direct support for 1394 in windows in an upcoming service release (making it even easier, you can still do it now with more software effort), and it's expected that they will require 1394 for windows logo approval in their hardware design "guide" for 2000. (that means that if you want to sell a PC with the "approved for windows" logo, you have to include it after July 1, 2000. that's one way in which microsoft/intel control the industry. The industry follows these "guides" religiously, because if you don't you lose all your business.) Microsoft and Intel have a whole chapter devoted to 1394 in the PC'99 System Design Guide doc, where 1394 is "strongly recommended". They even state that this will be upgraded to "required" in the next version. In other words, Microsoft and Intel are pushing this hard now. (so is compaq, actually...) Of course, Apple has pushed it for years, but that doesn't really mean anything. >Sony home components have been sporting a FW-like port in their backs for >several years also, but even they seem ambivalent with respect to >propagation of this potentially nice method of linking everything up. At >a >low end effort, even MIDI could be transposed upon it, with no data >changes >beyond the transport/protocol. But of course that would require a >mega-committee that can't even agree who belongs, to convene about THAT. >Which could also be a good reason why we've heard mostly theory about FW, >and a smattering of products. The Audio Engineering Society has working groups for defining audio transmission and audio system control over 1394. These have been in place for quite some time. I believe they have this more or less done and are hashing out arcane details. Yamaha has independently developed mLAN, which is an audio network using 1394, I think they may have even used some of that for the AES standard. I beleive the Midi Manufacturer's Association also has a working group defining MIDI over USB and 1394. All of these standards efforts have been going on for some time now. I don't follow it too closely, but as far as I know the work is mostly done and awaiting more common adoption of the 1394 interface. >Well, that's it then. They're all dragging their heels, folks. as noted, the industry is clearly not dragging any heels. As consumer needs for higher bandwidth transmission grow, the demand for 1394 has grown, and it's steadily getting here. The "they" in your sentence is really you....if people aren't lining up to buy it, nobody's going to rush to make it. >Who wants >to figure out how to transpose MIDI onto Ethernet? It's THERE already, >and >a standard worldwide... and could provide REAL "convergence", to use this >year's overused buzzword. > The trouble with Ethernet is it's a non-deterministic network architecture, and you can't guarantee arrival times of any data sent over it. For audio, this means dropouts, and for midi (or some similar control protocol), it means lots of synchronization and timing problems. This is why network architectures like ATM and 1394 are being adopted for these purposes instead of ethernet. anyway, speak from what you know, it's safer...:-) kim