OSC is a message transport protocol. It describes how to packetise messages, but not what they mean -- it doesn't define an application-level semantics. This is both an advantage (making it flexible, and malleable to requirements of ad-hoc projects) and a disadvantage (places a limit on seamless interoperability between COTS hardware). In general, OSC needs either (a) the sending and receiving endpoints to a priori agree on an application-level protocol (message schema), or (b) some kind of glue/mapping layer in either the sender or receiver that can translate and map schemas. Such a mapping layer is easy to construct if you're using a programmable environment. OSC has support in pretty much every programming language and many music environments and, like MIDI 1.0, is a viable DIY protocol.
By contrast, MIDI (both MIDI 1 and 2) are flexible application level protocols. For example, among other things, MIDI 1.0 describe schemas for musical notes, parameters, transport control, and time synchronization. Built-in application schemas allow devices that fit the application model to communicate in a relatively seamless way. I believe that MIDI 2.0 provides a more extensive schema, that includes (for example) device discovery and capability queries, and removes some limitations of the old schema. I'm not familiar enough with the details of the final MIDI 2.0 spec to say much more than that.
As I recall, some of the features of MIDI 2.0 (e.g. capability queries, discussed elsewhere on this page) were proposed for an "OSC 2.0", however the fine people at CNMAT who produced the OSC 1.0 spec didn't have the resources to sponsor 2.0 development, and no one else stepped up. In contrast, the MMA (MIDI Manufacturers Association), who sponsored the 2.0 spec, have all of the major music corporations as members (e.g Roland, Korg, Yamaha). That said, as I understand, the MIDI 2.0 process was open to anyone, and I know of at least one independent developer who was involved.
Will they compete? I suspect that the situation will continue much unchanged: commercial hardware will support MIDI (1 and/or 2), and as is currently the case, few commercial music devices will support OSC. OSC will likely continue to be the protocol of choice for custom projects using custom hardware, software and application schemas. Perhaps with time, as the tools improve and we get API support for MIDI 2.0 in operating systems and embedded libraries, it might become easy enough to develop MIDI 2.0 software to choose between OSC and MIDI 2.0.
I am working on VJ software, we are missing the capacity to associate preview icons for music events. I hope OSC 2.0 would allow that with application-level protocol by example... We tried to convince the music community 10 years ago but could not make it happen.
By contrast, MIDI (both MIDI 1 and 2) are flexible application level protocols. For example, among other things, MIDI 1.0 describe schemas for musical notes, parameters, transport control, and time synchronization. Built-in application schemas allow devices that fit the application model to communicate in a relatively seamless way. I believe that MIDI 2.0 provides a more extensive schema, that includes (for example) device discovery and capability queries, and removes some limitations of the old schema. I'm not familiar enough with the details of the final MIDI 2.0 spec to say much more than that.
As I recall, some of the features of MIDI 2.0 (e.g. capability queries, discussed elsewhere on this page) were proposed for an "OSC 2.0", however the fine people at CNMAT who produced the OSC 1.0 spec didn't have the resources to sponsor 2.0 development, and no one else stepped up. In contrast, the MMA (MIDI Manufacturers Association), who sponsored the 2.0 spec, have all of the major music corporations as members (e.g Roland, Korg, Yamaha). That said, as I understand, the MIDI 2.0 process was open to anyone, and I know of at least one independent developer who was involved.
Will they compete? I suspect that the situation will continue much unchanged: commercial hardware will support MIDI (1 and/or 2), and as is currently the case, few commercial music devices will support OSC. OSC will likely continue to be the protocol of choice for custom projects using custom hardware, software and application schemas. Perhaps with time, as the tools improve and we get API support for MIDI 2.0 in operating systems and embedded libraries, it might become easy enough to develop MIDI 2.0 software to choose between OSC and MIDI 2.0.
Edit: clarity.