5 ms·

MIDI 2.0 has USB as a pre-req. I’m not sure how this improves things. One of my chief complaints, and why I moved away from USB to an all-midi setup is how inte

MIDI 2.0 has USB as a pre-req. I’m not sure how this improves things. One of my chief complaints, and why I moved away from USB to an all-midi setup is how interrupts are handled, making USB sometimes unreliable, especially with large setups like mine. MIDI just works and is pretty easy to implement. I’ve never experienced a real limitation. Resolution has its workarounds but honestly isn’t all that limiting. What does 2.0 offer me that 1.0 doesn’t? I know it has new features, but I want a good argument for those features actually being useful.

jcal93 5y ago
I'm in your camp on this one. The new features are neat, but MIDI 1.0 being stupid-simple is its killer feature to me. Plus everything from the last 30yrs supporting it is a big plus. I love that I can take my 1980s SuperJX and fit it right into my setup with brand new stuff, and a brand new DAW, and everything just works.
- md8z 5y ago
  I don't know if I would call MIDI 1.0 simple in practice. It has a lot of really confusing idiosyncrasies, it's definitely got that feel of being a simple base that was organically developed and had tons of things piled into it over the years. The packet structure in MIDI 2.0 is a lot more... consistent, I guess is what you could say? I don't think you even need a state machine to implement it beyond the initial handshake.
sova 5y ago
Midi 1.0: 127 steps Midi 2.0: 4,294,967,296 steps https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange https://www.midi.org/midi-articles/details-about-midi-2-0-mi...
- romwell 5y ago
  Number big, protocol better! Ever heard of NRPN, my friend? There's a reason why this part of the MIDI spec is rarely used. And the reason is that the musicians don't need it. If you can hear stepping on your pitch bend or filter, it's not because MIDI, it's because the implementation on your device is stupid.
  - jmull 5y ago
    Yup. MIDI 2: solving problems musicians don't have and creating new problems! (Excessive complexity -- MIDI 1 was hard enough to implement. MIDI 2 is telling everyone to jump 10ft high -- good luck with that.)
    - mrandish 5y ago
      I agree that many of the things in MIDI 2.0 don't seem directly relevant to the bread-and-butter musicians, composers, mixers, producers and DJs who are the ultimate users. The numeric bumps in resolution, data and packets are all conceptually fine but it's not like they are addressing the standards gaps most holding back users and forward innovation. Personally, I was disappointed they didn't even make a stab toward addressing higher layers in the stack like standardizing multi-channel mixing control beyond the ancient 'defacto' Mackie HUI format or some attempt at a framework for software plugins running on hosts to display GUI on controllers (even something very open/extensible ala HTML/CSS). That could have unleashed waves of innovation from indie and smaller developers.
      - ace2358 5y ago
        Maybe I’m old fashioned but keep html/css the heck of my music instruments please and thank you.
        md8z 5y ago
        The suggestion was for a GUI running on the host, not on the instrument...
    - capableweb 5y ago
      > MIDI 1 was hard enough to implement MIDI 1 is one of the easiest protocols I've ever interfaced with myself. Getting started on any platform is easy, the API is not that large and it's relatively straightforward. You can on Linux write bytes directly to /dev/midi and get up and running really quickly, and the specification is not that big. See https://ccrma.stanford.edu/~craig/articles/linuxmidi/ https://ccrma.stanford.edu/~craig/articles/linuxmidi/ for some examples. What did you find hard in implementing MIDI 1? Would be nice to hear the opinion for something I haven't heard in real life (yet?).
- em3rgent0rdr 5y ago
  On this matter I must say for playing music live that the 127 steps provides a great deal of resolution. Good enough for me that I have never felt like my EWI's breath sensor was not fine enough or that my piano's touch sensor was not fine enough or that a CC knob didn't give enough resolution when turning slowly. Though if I listen closely to an isolated note I could tell there was a difference in loudness between two neighboring velocity steps, but probably couldn't tell in a live performance setting, and I would challenge listeners to see if they could tell the difference. I would say 127 steps is "good enough" or almost is for practical purposes...But that is just my datapoint and opinion. (For comparison, the most common video format is YUV420, and that averages to 12-bits per pixel, and most screen monitors use 8-bits for each color.) Had MIDI used the top bit to flag an optional extra byte for resolution, then that would have been great.
  - NateEag 5y ago
    I trained as a classical pianist before moving to the world of synthesizers ...and rock 'n' roll. The very few electric pianos I've played that didn't feel painfully limiting in dynamic expression were high-end instruments with a whole lot more than 127 velocity values. Similarly, I have the obscure but magnificent Nord G2X, which mostly uses MIDI for mapping physical knobs to parameters in patches, but its mod wheels are much higher resolution. I strongly prefer the mod wheels for params that cover a wide span, like filter cutoff frequency, because I can feel and hear the stair-stepping when using knobs.
jchw 5y ago
Aside from increased resolution, one of the biggest improvements is MPE. It allows controlling parameters on a per-note basis. A side effect of this is making microtonal music significantly easier to express, since you no longer need multiple channels to do per-note pitch-bending. MPE support is already probably more robust than MTS (MIDI Tuning Standard,) although I could be wrong on that. Essentially: for traditional western music, it seems to just offer better flexibility and precision, but it will make a huge difference for microtonal music. Honestly, being able to adjust parameters per-note simply makes sense. (I am not a musician, just a programmer who has dabbled in a small amount of music software and protocols.)
- romwell 5y ago
  MPE is not a MIDI 2.0 improvement. MPE is already implemented with MIDI 1.0. The only limitation of using channels for MPE is that you can't daisy-chain MPE devices... Which nobody really does anyway (most of my gear doesn't even have a THRU port).
- mrandish 5y ago
  MPE also enables increased expressiveness that new kinds of multi-dimensional controllers such as the ROLI keyboards leverage (new kinds of MPE controllers are shown at https://www.midi.org/midi-articles/midi-polyphonic-expression-mpe https://www.midi.org/midi-articles/midi-polyphonic-expressio...). While MPE is part of MIDI 1.0, many synth manufacturers never bothered to support it since their MIDI implementations were basically considered a "solved" problem by product management. Many of them never even bothered to support polyphonic after-touch except in their high-end keyboards. Now with MIDI 2.0 support becoming a 'checkbox' item for customers, all the manufacturers will need to revisit their MIDI implementations in upcoming product releases (some already have). I suspect many will use this as an opportunity to increase input dimensions and expressiveness - which is a very good thing for all of us users, even if they do so in ways which may have technically been possible before.
m-hilgendorf 5y ago
MIDI 2.0 is transport agnostic so it doesn't necessarily require USB, however USB is going to be the best solution for connecting many MIDI devices for awhile. The big underlying change is that MIDI 2 is duplex, which allows for device discovery, property exchange, and profile configuration. What that buys you is an arbitrary protocol for exchanging information about what things are connected to each other on the same network of devices. It should allow for a lot of cool features, like supplanting Mackie Control and Eucon with an open (or at least trivially open) protocol. One thing I think we'll see with these is more support for microtonal or arbitrary pitch systems that MIDI currently can't realize. Jitter compensation is built into the protocol too so it should resolve some of the timing issues with USB. Having read through the spec and written the data structures out for it already I'm not sold that it's overly complex. The additional annoyance is that it mandates JSON parsing but that isn't a tall order these days.
- WhitneyLand 5y ago
  What would you have recommended instead of JSON?
  - nitrogen 5y ago
    It's weird to put variable-length text-based serialization formats into something that has to perform in realtime no matter what, on potentially limited hardware.
  - m-hilgendorf 5y ago
    I think JSON makes a lot of sense. It's just orders of magnitude more complex to parse into useful data structures than MIDI1, or any other part of MIDI2. Since MIDI is already going the opposite direction of say AES67 and reinventing wheels is ok, a custom binary encoding would have made more sense to me. Something that can be encoded in a C89 struct without a ton of trouble or doesn't need much thought put into an allocator on bare metal devices to get the handshake working. I believe it's not strictly JSON though, I don't have the docs in front of me but iirc strings have a max length. So that's good.

jcal93 5y ago

I'm in your camp on this one. The new features are neat, but MIDI 1.0 being stupid-simple is its killer feature to me. Plus everything from the last 30yrs supporting it is a big plus. I love that I can take my 1980s SuperJX and fit it right into my setup with brand new stuff, and a brand new DAW, and everything just works.

md8z 5y ago
I don't know if I would call MIDI 1.0 simple in practice. It has a lot of really confusing idiosyncrasies, it's definitely got that feel of being a simple base that was organically developed and had tons of things piled into it over the years. The packet structure in MIDI 2.0 is a lot more... consistent, I guess is what you could say? I don't think you even need a state machine to implement it beyond the initial handshake.

sova 5y ago

Midi 1.0: 127 steps Midi 2.0: 4,294,967,296 steps https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange https://www.midi.org/midi-articles/details-about-midi-2-0-mi...

romwell 5y ago
Number big, protocol better! Ever heard of NRPN, my friend? There's a reason why this part of the MIDI spec is rarely used. And the reason is that the musicians don't need it. If you can hear stepping on your pitch bend or filter, it's not because MIDI, it's because the implementation on your device is stupid.
- jmull 5y ago
  Yup. MIDI 2: solving problems musicians don't have and creating new problems! (Excessive complexity -- MIDI 1 was hard enough to implement. MIDI 2 is telling everyone to jump 10ft high -- good luck with that.)
  - mrandish 5y ago
    I agree that many of the things in MIDI 2.0 don't seem directly relevant to the bread-and-butter musicians, composers, mixers, producers and DJs who are the ultimate users. The numeric bumps in resolution, data and packets are all conceptually fine but it's not like they are addressing the standards gaps most holding back users and forward innovation. Personally, I was disappointed they didn't even make a stab toward addressing higher layers in the stack like standardizing multi-channel mixing control beyond the ancient 'defacto' Mackie HUI format or some attempt at a framework for software plugins running on hosts to display GUI on controllers (even something very open/extensible ala HTML/CSS). That could have unleashed waves of innovation from indie and smaller developers.
    - ace2358 5y ago
      Maybe I’m old fashioned but keep html/css the heck of my music instruments please and thank you.
      - md8z 5y ago
        The suggestion was for a GUI running on the host, not on the instrument...
  - capableweb 5y ago
    > MIDI 1 was hard enough to implement MIDI 1 is one of the easiest protocols I've ever interfaced with myself. Getting started on any platform is easy, the API is not that large and it's relatively straightforward. You can on Linux write bytes directly to /dev/midi and get up and running really quickly, and the specification is not that big. See https://ccrma.stanford.edu/~craig/articles/linuxmidi/ https://ccrma.stanford.edu/~craig/articles/linuxmidi/ for some examples. What did you find hard in implementing MIDI 1? Would be nice to hear the opinion for something I haven't heard in real life (yet?).
em3rgent0rdr 5y ago
On this matter I must say for playing music live that the 127 steps provides a great deal of resolution. Good enough for me that I have never felt like my EWI's breath sensor was not fine enough or that my piano's touch sensor was not fine enough or that a CC knob didn't give enough resolution when turning slowly. Though if I listen closely to an isolated note I could tell there was a difference in loudness between two neighboring velocity steps, but probably couldn't tell in a live performance setting, and I would challenge listeners to see if they could tell the difference. I would say 127 steps is "good enough" or almost is for practical purposes...But that is just my datapoint and opinion. (For comparison, the most common video format is YUV420, and that averages to 12-bits per pixel, and most screen monitors use 8-bits for each color.) Had MIDI used the top bit to flag an optional extra byte for resolution, then that would have been great.
- NateEag 5y ago
  I trained as a classical pianist before moving to the world of synthesizers ...and rock 'n' roll. The very few electric pianos I've played that didn't feel painfully limiting in dynamic expression were high-end instruments with a whole lot more than 127 velocity values. Similarly, I have the obscure but magnificent Nord G2X, which mostly uses MIDI for mapping physical knobs to parameters in patches, but its mod wheels are much higher resolution. I strongly prefer the mod wheels for params that cover a wide span, like filter cutoff frequency, because I can feel and hear the stair-stepping when using knobs.

jchw 5y ago

Aside from increased resolution, one of the biggest improvements is MPE. It allows controlling parameters on a per-note basis. A side effect of this is making microtonal music significantly easier to express, since you no longer need multiple channels to do per-note pitch-bending. MPE support is already probably more robust than MTS (MIDI Tuning Standard,) although I could be wrong on that. Essentially: for traditional western music, it seems to just offer better flexibility and precision, but it will make a huge difference for microtonal music. Honestly, being able to adjust parameters per-note simply makes sense. (I am not a musician, just a programmer who has dabbled in a small amount of music software and protocols.)

romwell 5y ago
MPE is not a MIDI 2.0 improvement. MPE is already implemented with MIDI 1.0. The only limitation of using channels for MPE is that you can't daisy-chain MPE devices... Which nobody really does anyway (most of my gear doesn't even have a THRU port).
mrandish 5y ago
MPE also enables increased expressiveness that new kinds of multi-dimensional controllers such as the ROLI keyboards leverage (new kinds of MPE controllers are shown at https://www.midi.org/midi-articles/midi-polyphonic-expression-mpe https://www.midi.org/midi-articles/midi-polyphonic-expressio...). While MPE is part of MIDI 1.0, many synth manufacturers never bothered to support it since their MIDI implementations were basically considered a "solved" problem by product management. Many of them never even bothered to support polyphonic after-touch except in their high-end keyboards. Now with MIDI 2.0 support becoming a 'checkbox' item for customers, all the manufacturers will need to revisit their MIDI implementations in upcoming product releases (some already have). I suspect many will use this as an opportunity to increase input dimensions and expressiveness - which is a very good thing for all of us users, even if they do so in ways which may have technically been possible before.

m-hilgendorf 5y ago

MIDI 2.0 is transport agnostic so it doesn't necessarily require USB, however USB is going to be the best solution for connecting many MIDI devices for awhile. The big underlying change is that MIDI 2 is duplex, which allows for device discovery, property exchange, and profile configuration. What that buys you is an arbitrary protocol for exchanging information about what things are connected to each other on the same network of devices. It should allow for a lot of cool features, like supplanting Mackie Control and Eucon with an open (or at least trivially open) protocol. One thing I think we'll see with these is more support for microtonal or arbitrary pitch systems that MIDI currently can't realize. Jitter compensation is built into the protocol too so it should resolve some of the timing issues with USB. Having read through the spec and written the data structures out for it already I'm not sold that it's overly complex. The additional annoyance is that it mandates JSON parsing but that isn't a tall order these days.

WhitneyLand 5y ago
What would you have recommended instead of JSON?
- nitrogen 5y ago
  It's weird to put variable-length text-based serialization formats into something that has to perform in realtime no matter what, on potentially limited hardware.
- m-hilgendorf 5y ago
  I think JSON makes a lot of sense. It's just orders of magnitude more complex to parse into useful data structures than MIDI1, or any other part of MIDI2. Since MIDI is already going the opposite direction of say AES67 and reinventing wheels is ok, a custom binary encoding would have made more sense to me. Something that can be encoded in a C89 struct without a ton of trouble or doesn't need much thought put into an allocator on bare metal devices to get the handshake working. I believe it's not strictly JSON though, I don't have the docs in front of me but iirc strings have a max length. So that's good.