dt@yenta.alb.nm.us (David B. Thomas) (11/16/90)
All this talk of interfacing MIDI to PC serial ports got me thinking: Aren't MIDI messages horrendously inefficient? I seem to remember reading that normal note data, in order to be distinguishable from control messages, has to have the eighth bit turned off. But the data is still logically grouped in eight-bit chunks, so you get something like this: 0000xxxx 0000yyyy where "xxxxyyyy" is the actual data byte. Of course, the control messages use the other bits, but they still appear compressable. I'll bet with a smart midi card doing hardware compresssion (and buffering), you could cut the throughput of actual bits down to 19.2k and not lose any (valid) information. Comments? little david -- You mean you WUZ a Romanian....MUTHA!
maverick@fir.Berkeley.EDU (Vance Maverick) (11/16/90)
> Aren't MIDI messages horrendously inefficient? I seem to remember > reading that normal note data, in order to be distinguishable from > control messages, has to have the eighth bit turned off. But the > data is still logically grouped in eight-bit chunks, so you get > something like this: > > 0000xxxx > 0000yyyy No, note data is mostly 7 bits. (Some other data, like bender values, are 14 bits.) For example, pitch and velocity both have range 0-127. So for most information, you're only "wasting" one bit in eight. Four-bit nibbles are used for status code (eight values, all with high bit set) and channel numbers (a grossly inadequate sixteen). And these always share a byte, so it's pretty efficient on the whole.
scott@bbxsda.UUCP (Scott Amspoker) (11/16/90)
In article <1990Nov15.173346.11644@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: >All this talk of interfacing MIDI to PC serial ports got me thinking: > >Aren't MIDI messages horrendously inefficient? I seem to remember >reading that normal note data, in order to be distinguishable from >control messages, has to have the eighth bit turned off. But the >data is still logically grouped in eight-bit chunks, so you get >something like this: > >0000xxxx >0000yyyy > >where "xxxxyyyy" is the actual data byte. > >Of course, the control messages use the other bits, but they still appear >compressable. I'll bet with a smart midi card doing hardware compresssion >(and buffering), you could cut the throughput of actual bits down to 19.2k >and not lose any (valid) information. > > Comments? > > little david MIDI command bytes have the 8th bit on. MIDI data bytes have the 8th bit off. I know of no MIDI command or data that disregards the upper 4 bits. All in all, the MIDI data format is pretty efficient. However, sequencer files are likely to contain recurring "patterns" of data that would benifit from a compression scheme. Also, bulk dumps must frequently transfer 8-bit data within the 7-bit data bytes. This is left entirely to each manufacturer. Some manufacturers are lazy and simply do a hex transfer (I assume that's what you were describing). Others send 7 bytes of 7-bit data followed by an 8th byte containing the hi bits of the preceding 7 bytes. This 7/8 effeciency ratio seems OK to me. -- Scott Amspoker | Basis International, Albuquerque, NM | "I'm going out for a sandwich" (505) 345-5232 | - Ben unmvax.cs.unm.edu!bbx!bbxsda!scott |