Hacker News Reader

Comment by sharklazer | Hacker News Reader

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.

View on HN

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.

What would you have recommended instead of JSON?

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.

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.

JSON feels like a terrible choice to me, especially on the latency aspect of things.

msgpack comes to mind...

Mackie Control is open already (even if Mackie didn't really intend that to be the case).

Eucon is a perfect example of how to make a control protocol so powerful that nobody can ever really use it, or at least, not more than 5% of its capabilities.

Mackie and Eucon do not provide music performance data, so they would never be involved in pitch control. MTS can already be used to do microtonal stuff, but very few synthesizers are MTS aware, so the fact that you can do it already with MIDI 1.0 doesn't help a whole lot. Maybe 2.0 will encourage (a few?) more synth makers (soft/hard) to support MTS and/or the new stuff, but maybe it won't.

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.

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.

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.)

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).

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-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.

Midi 1.0: 127 steps

Midi 2.0: 4,294,967,296 steps

https://www.midi.org/midi-articles/details-about-midi-2-0-mi...

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.

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.)

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.

Maybe I’m old fashioned but keep html/css the heck of my music instruments please and thank you.

The suggestion was for a GUI running on the host, not on the instrument...

> 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/ 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?).

Parsing running status + sysex + system RT messages is non-trivial.

A full state machine for MIDI is much more complex than it tends to initially appear. But yeah, it's not rocket science. It's not even as hard as grappling with std::move()

Maybe the core specification isn't that big a deal if you're just trying to get started writing some note on/off messages, but the full set of specifications with all the controllers and sysex messages and extensions and supplements is pretty long: https://www.midi.org/specifications-old/item/the-midi-1-0-sp...

And you can add in that vendors also have weird proprietary sysex messages a lot of the time. Also I second a sibling comment here, there are a decent number of gotchas with the state machine.

If you're using only one 7-bit CC (and not an MSB/LSB pair) to control a filter cutoff parameter that can range from 20Hz to 20kHz, it's not possible to dial in the exact frequency you want to match a particular harmonic.

> 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.

Or because you are stepping across 5 octaves instead of just one.

I have not heard of NRPN until now. Thanks for the pointer. Adding frequency support for any frequency and adding whole-number ratio harmonizing would have been preferable to me personally.

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.

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.

Reply on news.ycombinator.com