> 1980's-era idiocy of MIDI, in that it only has 127 steps in its CC's (sheesh, not even a lousy byte!). Do you burn two controllers with fine/coarse adjustments? If so, how do you determine the scale for fine and/or coarse?
>
The choice to use 7 bit rather than 8 bit transmission in the original spec was pragmatic. If 8 bit had been used it would have added more than 10% of useless overhead to realtime messages (key on/off) and not really have improved the efficiency of other controls - 127 steps are too restrictive, but 256 would have been as well so double encoding would still have been a requirement. At the time, this overhead was quite a lot with a tranmission rate of just 31.25 Kb/s, and the use of more complex encoding would have been an effort for the 8 bit processors used in the early synths for which this was developed.
A vast number of the controllers are already linked up to fine/coarse, some of which have definitions regarding functionality, especially for tuning features. There is also the Non Registered Parameter feature that extends the number of continuous fine/coarse controllers to 14bits (16K resolution) at the expense of a few extra messages using the Data Entry CC. The extra messages do not necessarily add much further latency since few people actually run MIDI over MIDI cables - MIDI/USB and MIDI/FW are more common these days, the small MIDI messages running 200Mb/s plus is very little latency.
That is not to say there are not issues with Midi. It is difficult to get hold of all the diverse submitted alterations to the original spec, for example, without membership of the Midi Manufacturers Association. SYSEX messages only take members' registered IDs. There is one experimental sysex ID for schools and non-commercial use (see below) but beyond that a developer has to request a registered ID from the MMA to have garanteed interoperable sysex. I think its only $200 per year, however if you are writing a freeware app that could be a lot of lost meals. The lack of sysex for non-commercial use limits functionality. Most useful features have already been integrated into the spec without SYSEX however bulk dumping of device specific data is pretty much not possible. The use of the single '0x7D' non-commercial ID is restrictive, its a single number so it cannot be used to support sysex to multiple softsynths on the same midi bus - they could not tell who was to respond to the message, and they are also specified not to be used publicly, ie, if you implement it then you should not be placed on the same bus as a commercial product.
I don't think its really time for another spec, OSC is available, and MIDI has functioned and scaled pretty well over the last 20 years, its extremely widely deployed and is the standard since everybody implements it, even though it is not exactly open. I would like to see the 0x7D non-commerical sysex being hijacked though. A minimal extra layer of syntax on top of it would allow an open authority to deliver free IDs to open source and freeware programmes allowing them a reliable data exchange over this medium, it would just require that the first 3 or 4 bytes of an 0x7D sysex be used as another application identifier.
Nick.
Get news, entertainment and everything you care about at Live.com. Check it out!