13 ms·

MIDI 2.0, first major overhaul to music interface standard from 1983

264 points by davio 7y ago

unlinked_dll 7y ago
I wish they would have removed SysEx messages. They cause way more trouble than they're worth, now that we have property exchange/profile configuration built into the spec.
- dkersten 7y ago
  What's the problem that SysEx messages cause? I've only limited experience with them (having used them only to send config data to a device, in a way that didn't need the device to keep functioning while being updated, from a programming point of view, I found them quite convenient and simple, except perhaps the fact that you only get 7 bits per byte so may have to pack the data).
  - SeanLuke 7y ago
    [For the benefit of HN: SysEx is a special manufacturer-specific MIDI message which is undefined, so a synth manufacturer can use it for whatever he wishes] I build a lot of open source patch editors for older synthesizers. My beef with Sysex is that every manufacturer uses completely different approaches to defining their own proprietary messages with it. For example, nearly every synth in the universe has a sysex message for dumping a patch (a full set of parameter settings) from a synth to another or to a computer; but they define their messages is radically different ways, so I must construct an entirely different set of parsing and emitting tools for every single synthesizer, even within a given manufacturer. It's a nightmare. So continuing this example, if the MIDI association had gotten together early on and said that MIDI dumps should have a header that looks like THIS and then all the parameters in order, two bytes per parameter with no bit packing whatsoever, no two's complement, and end with a specific checksum, then I'd have written 10x more patch editors so far. I wouldn't have to write custom parsers and dumpers: I'd just provide a list of parameters and their bounds.
    - fit2rule 7y ago
      (Disclaimer: been working in synth industry for decades now..) Most SYSEX dumps are just dumps of the plain ol' structs that the synth engines are using to drive their output. A lot of synths don't have the processing power to do more than just dump the struct. So, it wouldn't really make much sense to have them all use the same struct - this can't be enforced too well. Forcing synth mfr's to all use the same struct means that, even if they have their own internal plain-old-structs, they'd need code to dump the SYSEX according to the standard.
      - SeanLuke 7y ago
        > Most SYSEX dumps are just dumps of the plain ol' structs that the synth engines are using to drive their output. A lot of synths don't have the processing power to do more than just dump the struct. I don't think it's processing power: it's stingy RAM utilization. Many bad actors (Kawai, Casio, later Yamaha) did crazy bit-packing of parameters rather than just keep them in a simple array, while the more sane (Oberheim, E-mu, Waldorf, early Yamaha) at least tried to pack in a consistent way. Other bad actors (ahem Korg, as late as 2000) decided to use, shall we say, creative parameter encodings, going even so far as embedding textified versions of parameter numbers into sysex byte streams. And many used all sorts of crazy schemes for banks and patch numbering, most of which are incompatible with one another. And it's not just encoding: basic synth patch dump features are missing from different models. There are five basic tasks that most synth editors require: - Change patch - Request a dump from working memory - Dump to working memory - Dump to patch RAM and save - Send a single parameter change (for any parameter) Manufacturers couldn't even agree to make machines which supported all five of these. Some machines (Yamaha) have no way to write to RAM. Some machines couldn't do single parameter changes. Some machines can't properly change patches in a consistent manner. Some machines have no patch request mechanism. Many machines can't dump to current working memory: only to patch RAM! The situation is only getting worse. Whereas in the past manufacturers at least attempted a complement of sysex messages, now many manufacturers can't even be bothered to allow access to their machines (Korg, Roland). Others treat their sysex messages as proprietary secrets (Arturia, Digitech, Alesis). There is only one truly good, shining actor in the open MIDI spec space, and that is Sequential. Which shouldn't be a surprise given who runs it.
  - unlinked_dll 7y ago
    I can't know how big a SysEx message is until run time, which makes buffering them somewhat complicated when you don't know what's in the SysEx message. This isn't uncommon in serial protocols, but MIDI has been lifted several layers above the UART it was designed for, and one of its strengths for everything but SysEx is that you exactly how big messages are going to be and preallocating space for them is trivial.
    - aikah 7y ago
      > I can't know how big a SysEx message is until run time, which makes buffering them somewhat complicated when you don't know what's in the SysEx message. That's the reason why you want to break compatibility with MIDI 1 spec? Really? Just like for an HTTP stream, you don't need to know how big the stream is to process it, just when it ends, there is no new problem to solve here.
      - unlinked_dll 7y ago
        No, I want there to be only one way to do something in the protocol and to remove arbitrary binary exchange, this is one pain point. It turns your "standard" into a Frankenstein's Monster of data exchange, and you'd think we'd have learned over the last few decades that ambiguity in specification of a communication protocol is just going to lead to headaches and incompatible/buggy hardware. It's also weird to say SysEx is needed for backwards compat with MIDI 1.0. You can just require a translation layer between MIDI 1.0 sysex and MIDI 2.0 configuration/property exchange for backwards compat. Opaque binary as a part of the protocol does not encourage compatibility among hardware.
        aikah 7y ago
        The MIDI spec was successful for 30+ years for a reason and manufacturers managed with SysEx without any issue, there is no justification for any "compatibility layer" whatsoever here. The problem wasn't the spec obviously.
        7y ago
  - uhoh-itsmaciek 7y ago
    It's been kind of a headache in Firefox's WebMIDI support plans (since SysEx is sometimes used for firmware updates and it's hard to explain "this page may hack your keyboard" in a permission request dialog): https://github.com/mozilla/standards-positions/issues/58#issuecomment-369067271 https://github.com/mozilla/standards-positions/issues/58#iss...
- deleted 7y ago
  [deleted]
- 8bitsrule 7y ago
  Lots of 1.0 instruments have only SysEx to load/save patches. A single patch may have hundreds of parameters. Whole libraries of patches exist; they can be loaded/saved at once with Sysex. So, no way.
  - unlinked_dll 7y ago
    I don't really see why that matters for a new protocol that fallbacks to MIDI 1.0, it's not a superset of MIDI 1.0. If your device only takes MIDI 1.0 SysEx for patches, anything that would send those patches via MIDI is going to do it on top of the fallback. What I'm saying is a new MIDI 2.0 device probably shouldn't be able to use SysEx. Either opt out of MIDI 1.0 and use the paradigms established or fallback to MIDI 1.0 and its limitations. Otherwise we're just going to get a mess of different implementations, and MIDI 2.0 will fail to be a successful standard.
PaulDavisThe1st 7y ago
This quote from the section on the Capability Inquiry: "The type of instant-matching that is, as of now, still based on proprietary messages between Ableton hardware and software (or similar systems from other companies) will instead be universally available through MIDI 2.0" is misleading. The "matching" between (say) Live and a Push 2 are not based on proprietary messages sent between them, but merely on both ends knowing which messages to send. That's why an open source DAW like Ardour can also interact with a Push 2, in the same "instant-matching" way that Live can. Since MIDI is an open protocol, it is always possible to determine what messages are being sent. The capability inquiry is a good idea, but it doesn't replace the sort of carefully-built match between the hardware controller and the software that already exists.
fao_ 7y ago
There's a standard? I googled a few weeks ago and obviously my google-fu was terrible because I didn't find a standards document for it
- AndrewDucker 7y ago
  https://www.midi.org/specifications-old/item/the-midi-1-0-specification https://www.midi.org/specifications-old/item/the-midi-1-0-sp...
  - robin_reala 7y ago
    But nothing seemingly available for 2.0?
    - nemacol 7y ago
      "...the new specification hasn't been fully ratified by the members of the MMA and the AMEI, many details and implications of the new spec are still unknown."
    - PascLeRasc 7y ago
      https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange https://www.midi.org/articles-old/details-about-midi-2-0-mid... The actual spec sheet is yet to be released, but this is a really great article about it.
jacquesm 7y ago
Midi works fine for anything keyboard based. As soon as you deviate from that it becomes an exercise in frustration. Much better article: https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange https://www.midi.org/articles-old/details-about-midi-2-0-mid...
- robin_reala 7y ago
  Not that I’m familiar with the subject, but this article[1] suggests that Roli’s Seaboard would need MIDI >1.0 to transmit per-note pressure and pitch bend info, and the Seaboard is definitely keyboard based. [1] https://reverb.com/news/roland-unveils-first-midi-2-ready-keyboard-controller-a-88mkii https://reverb.com/news/roland-unveils-first-midi-2-ready-ke...
  - fit2rule 7y ago
    MIDI 1.0 supports polyphonic pressure and aftertouch messages - just not a lot of keyboard manufacturers supported it, since its pretty processor intensive - not to send, but to sense...
    - deleted 7y ago
      [deleted]
  - PascLeRasc 7y ago
    Pitch bend has been on MIDI controllers since forever, more or less. I'm super excited for this synth though, with per-note pitch-bend and multiple instruments reacting to key pressure: https://www.youtube.com/watch?v=UjZ6SuWxBFg https://www.youtube.com/watch?v=UjZ6SuWxBFg
    - 52-6F-62 7y ago
      Coming from strings, that makes so much sense. Learning some keyed instruments I always found myself attempting to bend/vibrato in that way without thinking. Also, that man looks a lot like Garth Hudson... https://pbs.twimg.com/media/DjtfCgOUwAA6K7o.jpg:small https://pbs.twimg.com/media/DjtfCgOUwAA6K7o.jpg:small
sneakernets 7y ago
I'm so glad this happened, this may put an end to the many, many bespoke midi implementations I've come across. I participated in a piano competition over a decade ago (I believe it was sponsored by YAMAHA) which recorded all participants through an extended MIDI format that increased the resolution and bumped almost everything up to 1024 max from 127 max. With MIDI 2.0 this wouldn't even be required, all the functionality is included.
- elihu 7y ago
  > I'm so glad this happened, this may put an end to the many, many bespoke midi implementations I've come across. Maybe it will, but I'm not terribly optimistic that we'll avoid the scenario where the various manufacturers implement the parts of MIDI 2.0 that they care about, and we'll have another mess of partial implementations that aren't entirely compatible with each other. It might help if someone puts out an open-source highly portable reference implementation that everyone can use rather than every manufacturer writing everything from scratch.
tartoran 7y ago
For me MIDI 1.0 served my needs. I may look into 2.0 if the need arises. It is however great to know that it will be backwards compatible: MIDI 2.0 will be backwards compatible, meaning all new MIDI 2.0 devices will be able to use and send MIDI 1.0 data. And if, in time, you create a hybrid setup of old 1.0- and new 2.0-equipped machines, your rig's MIDI 2.0 models will interact together with the fresh capabilities of the new spec, while the MIDI 1.0 models will continue to work as they always have.
- wwweston 7y ago
  This is the most important feature. MIDI lives in a context where the computing world's conception of obsolescence would be even more hostile to owners than it is now; decades old hardware is still used and loved, keeping it part of the protocol is key.
  - ptah 7y ago
    This. I have switched to hardware and going DAWless purely because of the software culture of upgrading for upgrading's sake
- ptah 7y ago
  for me backwards compatibility would be the main priority for midi 2.0 any thing lessening it should be sacrificed
- zeeed 7y ago
  I remember people discussing the MIDI 2.0 standard back in 2005 and the arguments since then haven't changed. No one needed it back then and the idea that it would become a breakthrough 14 years later is beyond me because no one has needed it since. Wikipedia talking about that the protocol having been "researched" since then, that gave me a good chuckle. For reference in 2005 the iPhone didn't exist was two years away and people were wearing layered polo-shirts https://en.wikipedia.org/wiki/MIDI#MIDI_2.0 https://en.wikipedia.org/wiki/MIDI#MIDI_2.0
fortran77 7y ago
We have an organ in our office warehouse with 8 ranks of real pipes, and several dozen virtual ranks and it is MIDI controllable. MIDI does a poor job of mapping organs to MIDI messages. There's no good way to control stops (i.e., what stops are selected on which manual/pedal) and couplers without "overloading" a lot of the meta commands. And there's no way of defining which stops (which can be on any manual) are under expression. There's no way to represent a "tutti" stop, etc. And even for conventional "piano" instruments, which you'd think MIDI would work well for, it's lacking. It doesn't have pedal velocity or position (often the damper pedal is held at some in between position) and it doesn't have key position. Advanced "player" systems, like the Bosendorfer SE or Disklavier Pro overload other MIDI messages to account for this. Anyone who plays a real piano will see MIDI's problems. At the very least, every keyboard instrument like Organs and Pianos should be 100% controllable from MIDI.
- 6581 7y ago
  > It doesn't have pedal velocity or position (often the damper pedal is held at some in between position) It does have pedal position. Pedal data is transmitted as a control change message (e.g. CC#64 for damper) with a 7-bit data value. Many recent digital pianos support half-pedalling including transmitting and receiving the pedal position via MIDI.
  - scarecrowbob 7y ago
    Indeed, this is true. I've often been super frustrated by things that receive MIDI: they don't expose certain controls to CC, or they don't respond to multiple channels, or they don;'t pass certain information to the Thru port. But often what is frustrating is that it's do-able in MIDI, it just wasn't implemented well on the device.
- scarecrowbob 7y ago
  That's super cool that you have access to a pipe organ. I spent a lot of time in my youth building a pipe organ with my dad and the church we went to. They are amazing instruments. I'm having a hard time understanding how you'd have a hard time implementing an organ control setup over MIDI. Like I get that there there is no specific tutti setting, but why couldn't you just have all the ranks be CC channels and then have the various settings be program numbers, so tutti then is jsut calling up the program with all the stops open? I do play a real piano, and I haven't been seeing problems with MIDI in the time I've been using it. Like, I've seen a lot of issues with piano synthesizer/sampler implementations... but the basic interface of the piano seems (at least to me) fairly easy to represent in MIDI... Can you help me out by describing what kinds of problems you're seeing? Like I say, could just be my own lack of experience, but you've bade me curious what I'm possibly missing.
kazinator 7y ago
What will Midi 2.0 mean for musicians? I suspect: frustrations with shit not working with other shit, like it used to with MIDI, and a big decrement in DIY hackability. USB is in the mix! Pretty much `nuff said, but I will say it anyway. USB is a complex beast with documentation that is a good fraction of a foot high, if printed out in all its versions on standard letter sized laser paper. If you bring that into any standard, that is now part of your standard. USB connectors do not have the optical isolation of MIDI current loops; USB interconnecting will bring in noisy ground loops that will have musicians and recording engineers pulling out their hair. The clever thing in MIDI is that a device which sends messages over MIDI to another device drives current pulses (not voltage). These current pulses activate an octo-coupling device in the receiver such as a phototransistor. There is no galvanic connection between the devices; they don't share any ground or anything. All sorts of talented musicians have done incredible things with MIDI. The resolution of MIDI has been just fine for people with real chops. MIDI 2.0 isn't going to solve the real problem: talent vacuum.
- Polylactic_acid 7y ago
  USB midi is already a thing though. And its a real pain to use if you want to connect 2 devices together where one of them isn't your computer.
- ipsum2 7y ago
  From the article: > When you connect devices together, the Capability Inquiry will immediately determine what each instrument is able to do: Your new MIDI 2.0 controller will automatically know which pieces of your rig are equipped with MIDI 1.0, which are capable of 2.0, and tailor its messages accordingly. So hopefully backward compatibility Just WorksTM.
- exabrial 7y ago
  MiDI 2.0 is not isolated? Crap. Literally any of my guitar pedals when connected by USB instantly injects noise into my electric guitar signal chain, and isolated USB hubs are practically non-existent.
  - 7y ago
lioeters 7y ago
For me, one of the highlights is the higher resolution of values, for example for control messages, from 7 bits (0~127) up to 32 bits.
Jamwinner 7y ago
I am hopeful, but skeptical. All you musicians who can't feel the MIDI 1.0 delay need to play on some accoustical insturments and get what you have been missing. That couple of ms between each note make every chord a rapid appregio, drum hit a flam, and it gets worse as control data (much less sysex!) is added. While I was hoping for a timing-agnostic standard, what we seem to be getting is not terrible from what I can see. Does anyone have a link to an actual spec sheet or prototype implementation?
- scarecrowbob 7y ago
  I wish my timing was that good. I've been using MIDI for decades and not ever noticed it when stuff was setup correctly. I mean, I play guitars and pedal steel, banjo, dobro, accordion, etc. all acoustically (or, more likely, "in the analog domain"). Maybe I just need to practice more or listen harder. Do you have any suggestions on how I can improve my timing and/or hearing to experience this?
  - RuleOfBirds 7y ago
    Ya. As someone who plays acoustic piano, guitar, ukulele, and ocarina...using MIDI 1.0 to connect my electronic gear hasn't created any latency that's noticeable to me. Sure if you're sending things to and back through a DAW or whatnot it can get noticeable, but that's processing/software time, not MIDI 1.0. I can't tell the difference between a 320kbps mp3 and FLAC either, but I'm not worried about it.
    - usrusr 7y ago
      It's not latency that GP was bemoaning, it's the sequential nature: two note-on measures cannot arrive at exactly the same time. If it was just constant latency, GP probably wouldn't mind (or criticize that, but it would be a completely different argument). Latency alone can actually be worse with real instruments because electrical signals easily outrun sound. (Nerve conduction velocity however is the worst of all, it's a wonder that we can function at all with that shitty data transmission)
_delirium 7y ago
Kind of strange. This seems to be intended for the case where you connect your devices with something like USB, not with physical MIDI cables, and use MIDI as just an event/messaging protocol on top of the generic data connection. And it's true that MIDI has some limitations in that setup. But for that use-case, Open Sound Control (OSC) already exists, and is supported by almost everything on the software side, plus a growing number of things on the hardware side. Why not just use that?
- RossBencina 7y ago
  MIDI is not "just an event/messaging protocol", although it could be used like that. MIDI describes an application-level schema for "channels" which allow for the dynamic control of "notes" including pitch, poly after-touch, etc. It also provides for channel-level control parameters, various special application-level events. Global clock transport, bulk data transfer, etc. It's true that you could implement all of these with OSC, (indeed there is a standard embedding of the short MIDI messages into OSC), but OSC is in general silent on application-level semantics. This makes OSC a much better choice if you want to implement some other semantic, but you still need an application level schema for commercial music devices, and that doesn't exist.
deleted 7y ago
[deleted]
andyjpb 7y ago
Whenever I talk friends who are interested in such things, they tell me that Open Sound Control ( https://en.wikipedia.org/wiki/Open_Sound_Control https://en.wikipedia.org/wiki/Open_Sound_Control ) is the new MIDI. It seems to support a lot more than traditional MIDI, especially in terms of control and synchronisation. Does anyone have any idea how well MIDI 2.0 and OSC will compete with or complement each other?
- RossBencina 7y ago
  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. Edit: clarity.
Archit3ch 7y ago
I got to see it in ADC19. For me the "2.0" part is pure marketing. However, since the industry has moved on (e.g. MPE) it's nice to standardize on something.
hoistbypetard 7y ago
I really hope the background compatibility is idiot-proof. Because it's really been great. My Roland EP-9 from the mid-90s is easily the oldest device I have that I can connect to my iPad and have it just work with modern software. (Granted, a dongle or two is involved...) And it's worked with every computer I've cared to connect it to in years prior. That strikes me as a sign of a standard well-done.
ptah 7y ago
> Is this important to me? maybe. > Is this something that's worth potentially getting rid of something I love for new capabilities that may or may not be compelling? never
FraKtus 7y ago
Because MIDI 2.0 is bi-directional, will it allow us to exchange preview icons for each individual MIDI note? I am working on VJ software and we want to display the video loop associated with each MIDI key...

264 points by davio 7y ago

I wish they would have removed SysEx messages. They cause way more trouble than they're worth, now that we have property exchange/profile configuration built into the spec.

dkersten 7y ago
What's the problem that SysEx messages cause? I've only limited experience with them (having used them only to send config data to a device, in a way that didn't need the device to keep functioning while being updated, from a programming point of view, I found them quite convenient and simple, except perhaps the fact that you only get 7 bits per byte so may have to pack the data).
- SeanLuke 7y ago
  [For the benefit of HN: SysEx is a special manufacturer-specific MIDI message which is undefined, so a synth manufacturer can use it for whatever he wishes] I build a lot of open source patch editors for older synthesizers. My beef with Sysex is that every manufacturer uses completely different approaches to defining their own proprietary messages with it. For example, nearly every synth in the universe has a sysex message for dumping a patch (a full set of parameter settings) from a synth to another or to a computer; but they define their messages is radically different ways, so I must construct an entirely different set of parsing and emitting tools for every single synthesizer, even within a given manufacturer. It's a nightmare. So continuing this example, if the MIDI association had gotten together early on and said that MIDI dumps should have a header that looks like THIS and then all the parameters in order, two bytes per parameter with no bit packing whatsoever, no two's complement, and end with a specific checksum, then I'd have written 10x more patch editors so far. I wouldn't have to write custom parsers and dumpers: I'd just provide a list of parameters and their bounds.
  - fit2rule 7y ago
    (Disclaimer: been working in synth industry for decades now..) Most SYSEX dumps are just dumps of the plain ol' structs that the synth engines are using to drive their output. A lot of synths don't have the processing power to do more than just dump the struct. So, it wouldn't really make much sense to have them all use the same struct - this can't be enforced too well. Forcing synth mfr's to all use the same struct means that, even if they have their own internal plain-old-structs, they'd need code to dump the SYSEX according to the standard.
    - SeanLuke 7y ago
      > Most SYSEX dumps are just dumps of the plain ol' structs that the synth engines are using to drive their output. A lot of synths don't have the processing power to do more than just dump the struct. I don't think it's processing power: it's stingy RAM utilization. Many bad actors (Kawai, Casio, later Yamaha) did crazy bit-packing of parameters rather than just keep them in a simple array, while the more sane (Oberheim, E-mu, Waldorf, early Yamaha) at least tried to pack in a consistent way. Other bad actors (ahem Korg, as late as 2000) decided to use, shall we say, creative parameter encodings, going even so far as embedding textified versions of parameter numbers into sysex byte streams. And many used all sorts of crazy schemes for banks and patch numbering, most of which are incompatible with one another. And it's not just encoding: basic synth patch dump features are missing from different models. There are five basic tasks that most synth editors require: - Change patch - Request a dump from working memory - Dump to working memory - Dump to patch RAM and save - Send a single parameter change (for any parameter) Manufacturers couldn't even agree to make machines which supported all five of these. Some machines (Yamaha) have no way to write to RAM. Some machines couldn't do single parameter changes. Some machines can't properly change patches in a consistent manner. Some machines have no patch request mechanism. Many machines can't dump to current working memory: only to patch RAM! The situation is only getting worse. Whereas in the past manufacturers at least attempted a complement of sysex messages, now many manufacturers can't even be bothered to allow access to their machines (Korg, Roland). Others treat their sysex messages as proprietary secrets (Arturia, Digitech, Alesis). There is only one truly good, shining actor in the open MIDI spec space, and that is Sequential. Which shouldn't be a surprise given who runs it.
- unlinked_dll 7y ago
  I can't know how big a SysEx message is until run time, which makes buffering them somewhat complicated when you don't know what's in the SysEx message. This isn't uncommon in serial protocols, but MIDI has been lifted several layers above the UART it was designed for, and one of its strengths for everything but SysEx is that you exactly how big messages are going to be and preallocating space for them is trivial.
  - aikah 7y ago
    > I can't know how big a SysEx message is until run time, which makes buffering them somewhat complicated when you don't know what's in the SysEx message. That's the reason why you want to break compatibility with MIDI 1 spec? Really? Just like for an HTTP stream, you don't need to know how big the stream is to process it, just when it ends, there is no new problem to solve here.
    - unlinked_dll 7y ago
      No, I want there to be only one way to do something in the protocol and to remove arbitrary binary exchange, this is one pain point. It turns your "standard" into a Frankenstein's Monster of data exchange, and you'd think we'd have learned over the last few decades that ambiguity in specification of a communication protocol is just going to lead to headaches and incompatible/buggy hardware. It's also weird to say SysEx is needed for backwards compat with MIDI 1.0. You can just require a translation layer between MIDI 1.0 sysex and MIDI 2.0 configuration/property exchange for backwards compat. Opaque binary as a part of the protocol does not encourage compatibility among hardware.
      - aikah 7y ago
        The MIDI spec was successful for 30+ years for a reason and manufacturers managed with SysEx without any issue, there is no justification for any "compatibility layer" whatsoever here. The problem wasn't the spec obviously.
        7y ago
- uhoh-itsmaciek 7y ago
  It's been kind of a headache in Firefox's WebMIDI support plans (since SysEx is sometimes used for firmware updates and it's hard to explain "this page may hack your keyboard" in a permission request dialog): https://github.com/mozilla/standards-positions/issues/58#issuecomment-369067271 https://github.com/mozilla/standards-positions/issues/58#iss...
deleted 7y ago
[deleted]
8bitsrule 7y ago
Lots of 1.0 instruments have only SysEx to load/save patches. A single patch may have hundreds of parameters. Whole libraries of patches exist; they can be loaded/saved at once with Sysex. So, no way.
- unlinked_dll 7y ago
  I don't really see why that matters for a new protocol that fallbacks to MIDI 1.0, it's not a superset of MIDI 1.0. If your device only takes MIDI 1.0 SysEx for patches, anything that would send those patches via MIDI is going to do it on top of the fallback. What I'm saying is a new MIDI 2.0 device probably shouldn't be able to use SysEx. Either opt out of MIDI 1.0 and use the paradigms established or fallback to MIDI 1.0 and its limitations. Otherwise we're just going to get a mess of different implementations, and MIDI 2.0 will fail to be a successful standard.

PaulDavisThe1st 7y ago

This quote from the section on the Capability Inquiry: "The type of instant-matching that is, as of now, still based on proprietary messages between Ableton hardware and software (or similar systems from other companies) will instead be universally available through MIDI 2.0" is misleading. The "matching" between (say) Live and a Push 2 are not based on proprietary messages sent between them, but merely on both ends knowing which messages to send. That's why an open source DAW like Ardour can also interact with a Push 2, in the same "instant-matching" way that Live can. Since MIDI is an open protocol, it is always possible to determine what messages are being sent. The capability inquiry is a good idea, but it doesn't replace the sort of carefully-built match between the hardware controller and the software that already exists.

fao_ 7y ago

There's a standard? I googled a few weeks ago and obviously my google-fu was terrible because I didn't find a standards document for it

AndrewDucker 7y ago
https://www.midi.org/specifications-old/item/the-midi-1-0-specification https://www.midi.org/specifications-old/item/the-midi-1-0-sp...
- robin_reala 7y ago
  But nothing seemingly available for 2.0?
  - nemacol 7y ago
    "...the new specification hasn't been fully ratified by the members of the MMA and the AMEI, many details and implications of the new spec are still unknown."
  - PascLeRasc 7y ago
    https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange https://www.midi.org/articles-old/details-about-midi-2-0-mid... The actual spec sheet is yet to be released, but this is a really great article about it.

jacquesm 7y ago

Midi works fine for anything keyboard based. As soon as you deviate from that it becomes an exercise in frustration. Much better article: https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange https://www.midi.org/articles-old/details-about-midi-2-0-mid...

robin_reala 7y ago
Not that I’m familiar with the subject, but this article[1] suggests that Roli’s Seaboard would need MIDI >1.0 to transmit per-note pressure and pitch bend info, and the Seaboard is definitely keyboard based. [1] https://reverb.com/news/roland-unveils-first-midi-2-ready-keyboard-controller-a-88mkii https://reverb.com/news/roland-unveils-first-midi-2-ready-ke...
- fit2rule 7y ago
  MIDI 1.0 supports polyphonic pressure and aftertouch messages - just not a lot of keyboard manufacturers supported it, since its pretty processor intensive - not to send, but to sense...
  - deleted 7y ago
    [deleted]
- PascLeRasc 7y ago
  Pitch bend has been on MIDI controllers since forever, more or less. I'm super excited for this synth though, with per-note pitch-bend and multiple instruments reacting to key pressure: https://www.youtube.com/watch?v=UjZ6SuWxBFg https://www.youtube.com/watch?v=UjZ6SuWxBFg
  - 52-6F-62 7y ago
    Coming from strings, that makes so much sense. Learning some keyed instruments I always found myself attempting to bend/vibrato in that way without thinking. Also, that man looks a lot like Garth Hudson... https://pbs.twimg.com/media/DjtfCgOUwAA6K7o.jpg:small https://pbs.twimg.com/media/DjtfCgOUwAA6K7o.jpg:small

sneakernets 7y ago

I'm so glad this happened, this may put an end to the many, many bespoke midi implementations I've come across. I participated in a piano competition over a decade ago (I believe it was sponsored by YAMAHA) which recorded all participants through an extended MIDI format that increased the resolution and bumped almost everything up to 1024 max from 127 max. With MIDI 2.0 this wouldn't even be required, all the functionality is included.

elihu 7y ago
> I'm so glad this happened, this may put an end to the many, many bespoke midi implementations I've come across. Maybe it will, but I'm not terribly optimistic that we'll avoid the scenario where the various manufacturers implement the parts of MIDI 2.0 that they care about, and we'll have another mess of partial implementations that aren't entirely compatible with each other. It might help if someone puts out an open-source highly portable reference implementation that everyone can use rather than every manufacturer writing everything from scratch.

tartoran 7y ago

For me MIDI 1.0 served my needs. I may look into 2.0 if the need arises. It is however great to know that it will be backwards compatible: MIDI 2.0 will be backwards compatible, meaning all new MIDI 2.0 devices will be able to use and send MIDI 1.0 data. And if, in time, you create a hybrid setup of old 1.0- and new 2.0-equipped machines, your rig's MIDI 2.0 models will interact together with the fresh capabilities of the new spec, while the MIDI 1.0 models will continue to work as they always have.

wwweston 7y ago
This is the most important feature. MIDI lives in a context where the computing world's conception of obsolescence would be even more hostile to owners than it is now; decades old hardware is still used and loved, keeping it part of the protocol is key.
- ptah 7y ago
  This. I have switched to hardware and going DAWless purely because of the software culture of upgrading for upgrading's sake
ptah 7y ago
for me backwards compatibility would be the main priority for midi 2.0 any thing lessening it should be sacrificed
zeeed 7y ago
I remember people discussing the MIDI 2.0 standard back in 2005 and the arguments since then haven't changed. No one needed it back then and the idea that it would become a breakthrough 14 years later is beyond me because no one has needed it since. Wikipedia talking about that the protocol having been "researched" since then, that gave me a good chuckle. For reference in 2005 the iPhone didn't exist was two years away and people were wearing layered polo-shirts https://en.wikipedia.org/wiki/MIDI#MIDI_2.0 https://en.wikipedia.org/wiki/MIDI#MIDI_2.0

fortran77 7y ago

We have an organ in our office warehouse with 8 ranks of real pipes, and several dozen virtual ranks and it is MIDI controllable. MIDI does a poor job of mapping organs to MIDI messages. There's no good way to control stops (i.e., what stops are selected on which manual/pedal) and couplers without "overloading" a lot of the meta commands. And there's no way of defining which stops (which can be on any manual) are under expression. There's no way to represent a "tutti" stop, etc. And even for conventional "piano" instruments, which you'd think MIDI would work well for, it's lacking. It doesn't have pedal velocity or position (often the damper pedal is held at some in between position) and it doesn't have key position. Advanced "player" systems, like the Bosendorfer SE or Disklavier Pro overload other MIDI messages to account for this. Anyone who plays a real piano will see MIDI's problems. At the very least, every keyboard instrument like Organs and Pianos should be 100% controllable from MIDI.

6581 7y ago
> It doesn't have pedal velocity or position (often the damper pedal is held at some in between position) It does have pedal position. Pedal data is transmitted as a control change message (e.g. CC#64 for damper) with a 7-bit data value. Many recent digital pianos support half-pedalling including transmitting and receiving the pedal position via MIDI.
- scarecrowbob 7y ago
  Indeed, this is true. I've often been super frustrated by things that receive MIDI: they don't expose certain controls to CC, or they don't respond to multiple channels, or they don;'t pass certain information to the Thru port. But often what is frustrating is that it's do-able in MIDI, it just wasn't implemented well on the device.
scarecrowbob 7y ago
That's super cool that you have access to a pipe organ. I spent a lot of time in my youth building a pipe organ with my dad and the church we went to. They are amazing instruments. I'm having a hard time understanding how you'd have a hard time implementing an organ control setup over MIDI. Like I get that there there is no specific tutti setting, but why couldn't you just have all the ranks be CC channels and then have the various settings be program numbers, so tutti then is jsut calling up the program with all the stops open? I do play a real piano, and I haven't been seeing problems with MIDI in the time I've been using it. Like, I've seen a lot of issues with piano synthesizer/sampler implementations... but the basic interface of the piano seems (at least to me) fairly easy to represent in MIDI... Can you help me out by describing what kinds of problems you're seeing? Like I say, could just be my own lack of experience, but you've bade me curious what I'm possibly missing.

kazinator 7y ago

What will Midi 2.0 mean for musicians? I suspect: frustrations with shit not working with other shit, like it used to with MIDI, and a big decrement in DIY hackability. USB is in the mix! Pretty much `nuff said, but I will say it anyway. USB is a complex beast with documentation that is a good fraction of a foot high, if printed out in all its versions on standard letter sized laser paper. If you bring that into any standard, that is now part of your standard. USB connectors do not have the optical isolation of MIDI current loops; USB interconnecting will bring in noisy ground loops that will have musicians and recording engineers pulling out their hair. The clever thing in MIDI is that a device which sends messages over MIDI to another device drives current pulses (not voltage). These current pulses activate an octo-coupling device in the receiver such as a phototransistor. There is no galvanic connection between the devices; they don't share any ground or anything. All sorts of talented musicians have done incredible things with MIDI. The resolution of MIDI has been just fine for people with real chops. MIDI 2.0 isn't going to solve the real problem: talent vacuum.

Polylactic_acid 7y ago
USB midi is already a thing though. And its a real pain to use if you want to connect 2 devices together where one of them isn't your computer.
ipsum2 7y ago
From the article: > When you connect devices together, the Capability Inquiry will immediately determine what each instrument is able to do: Your new MIDI 2.0 controller will automatically know which pieces of your rig are equipped with MIDI 1.0, which are capable of 2.0, and tailor its messages accordingly. So hopefully backward compatibility Just WorksTM.
exabrial 7y ago
MiDI 2.0 is not isolated? Crap. Literally any of my guitar pedals when connected by USB instantly injects noise into my electric guitar signal chain, and isolated USB hubs are practically non-existent.
- 7y ago

lioeters 7y ago

For me, one of the highlights is the higher resolution of values, for example for control messages, from 7 bits (0~127) up to 32 bits.

Jamwinner 7y ago

I am hopeful, but skeptical. All you musicians who can't feel the MIDI 1.0 delay need to play on some accoustical insturments and get what you have been missing. That couple of ms between each note make every chord a rapid appregio, drum hit a flam, and it gets worse as control data (much less sysex!) is added. While I was hoping for a timing-agnostic standard, what we seem to be getting is not terrible from what I can see. Does anyone have a link to an actual spec sheet or prototype implementation?

scarecrowbob 7y ago
I wish my timing was that good. I've been using MIDI for decades and not ever noticed it when stuff was setup correctly. I mean, I play guitars and pedal steel, banjo, dobro, accordion, etc. all acoustically (or, more likely, "in the analog domain"). Maybe I just need to practice more or listen harder. Do you have any suggestions on how I can improve my timing and/or hearing to experience this?
- RuleOfBirds 7y ago
  Ya. As someone who plays acoustic piano, guitar, ukulele, and ocarina...using MIDI 1.0 to connect my electronic gear hasn't created any latency that's noticeable to me. Sure if you're sending things to and back through a DAW or whatnot it can get noticeable, but that's processing/software time, not MIDI 1.0. I can't tell the difference between a 320kbps mp3 and FLAC either, but I'm not worried about it.
  - usrusr 7y ago
    It's not latency that GP was bemoaning, it's the sequential nature: two note-on measures cannot arrive at exactly the same time. If it was just constant latency, GP probably wouldn't mind (or criticize that, but it would be a completely different argument). Latency alone can actually be worse with real instruments because electrical signals easily outrun sound. (Nerve conduction velocity however is the worst of all, it's a wonder that we can function at all with that shitty data transmission)

_delirium 7y ago

Kind of strange. This seems to be intended for the case where you connect your devices with something like USB, not with physical MIDI cables, and use MIDI as just an event/messaging protocol on top of the generic data connection. And it's true that MIDI has some limitations in that setup. But for that use-case, Open Sound Control (OSC) already exists, and is supported by almost everything on the software side, plus a growing number of things on the hardware side. Why not just use that?

RossBencina 7y ago
MIDI is not "just an event/messaging protocol", although it could be used like that. MIDI describes an application-level schema for "channels" which allow for the dynamic control of "notes" including pitch, poly after-touch, etc. It also provides for channel-level control parameters, various special application-level events. Global clock transport, bulk data transfer, etc. It's true that you could implement all of these with OSC, (indeed there is a standard embedding of the short MIDI messages into OSC), but OSC is in general silent on application-level semantics. This makes OSC a much better choice if you want to implement some other semantic, but you still need an application level schema for commercial music devices, and that doesn't exist.

deleted 7y ago

[deleted]

andyjpb 7y ago

Whenever I talk friends who are interested in such things, they tell me that Open Sound Control ( https://en.wikipedia.org/wiki/Open_Sound_Control https://en.wikipedia.org/wiki/Open_Sound_Control ) is the new MIDI. It seems to support a lot more than traditional MIDI, especially in terms of control and synchronisation. Does anyone have any idea how well MIDI 2.0 and OSC will compete with or complement each other?

RossBencina 7y ago
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. Edit: clarity.

Archit3ch 7y ago

I got to see it in ADC19. For me the "2.0" part is pure marketing. However, since the industry has moved on (e.g. MPE) it's nice to standardize on something.

hoistbypetard 7y ago

I really hope the background compatibility is idiot-proof. Because it's really been great. My Roland EP-9 from the mid-90s is easily the oldest device I have that I can connect to my iPad and have it just work with modern software. (Granted, a dongle or two is involved...) And it's worked with every computer I've cared to connect it to in years prior. That strikes me as a sign of a standard well-done.

ptah 7y ago

> Is this important to me? maybe. > Is this something that's worth potentially getting rid of something I love for new capabilities that may or may not be compelling? never

FraKtus 7y ago

Because MIDI 2.0 is bi-directional, will it allow us to exchange preview icons for each individual MIDI note? I am working on VJ software and we want to display the video loop associated with each MIDI key...