top | item 29051616

How will MIDI 2.0 change music? (2020)

179 points| kelnos | 4 years ago |qz.com

161 comments

order
[+] strenholme|4 years ago|reply
Now, I agree that MIDI 1.0 was designed for keyboard based synthesizers, and I know that complaints about MIDI latency have been around about as long as MIDI has been. So, yes, it has always been imperfect.

However, the nice thing about MIDI is that it allows me to hook up my 2020/2021 synthesizer (a Behringer 2600) to a 1987 sequencer (a Yamaha QX5), a 2015 synth (a Roland JD-Xi), or pretty much any piece of pro synth gear made since 1983.

Now, with MIDI-over-USB or what not, we lose something which makes MIDI very nice: We can connect a hardware keyboard to a dedicates sound module without having to have a computer involved. While there are USB host synths which one can connect a MIDI-only-over-USB keyboard to directly, they are few and far between (my JD-Xi has USB, as does my 2600 and Arturia Keylab controller, but all three can only be hooked up to a computer with USB)

Until MIDI 2.0 has a way to allow synths to be connected to each other without involving computers, and there is a standard way to do that (I think USB-C would probably be best for this), DIN MIDI 1.0 will be a part of pro and bedroom recording studios.

[+] gary_0|4 years ago|reply
> without having to have a computer involved

I shudder to think of a future where musical instruments require you to download an app to use them; where not only are your stove and washing machine phoning home, but your piano as well. No thanks.

[+] xyzzy123|4 years ago|reply
I will shill for the retrokits rk006 all day long (I am not involved and do not benefit from the project).

https://retrokits.com/shop/rk006/

It's a midi usb host and multi-port thru-box that even boosts succulent growth while you make DAW-less jam.

It's particularly good for bridging USB and DIN midi.

[+] ssalazar|4 years ago|reply
Agreed- though for MIDI 1.0 Kenton has some helpful boxes that act as a USB MIDI host to DIN MIDI converter.
[+] musicale|4 years ago|reply
We need more in the way of peer-to-peer and/or switchable USB (though I'm not quite sure how charging/power switching should work.) I remember reading about how to get USB to work peer-to-peer (e.g. like a simple bidirectional serial or ethernet cable) but practically it seems very hard.

Perhaps USB-C can do it as you suggest?

[+] nyanpasu64|4 years ago|reply
Replying to a past comment (https://news.ycombinator.com/item?id=22188146):

> - Violins come last, and it doesn't really matter because they're lazy and they'll take a few hundred milliseconds to really kick in anyway.

I think the assumption that violins don't need strong staccato/marcato attacks is wrong. I've needed it in the past, and was unable to get it from soundfonts which only have slow-attack samples. This issue is omnipresent in off-the-shelf soundfonts, and I've also sometimes seen poor articulation in music I've heard made using commercial sound libraries (which I've never purchased or pirated so I can't judge myself).

As an example of a piece suffering from slow attacks, https://www.youtube.com/watch?v=ua5VJt6jkaU is a nice remix, but feels sloppy because the flute, strings, and violin's 32nd notes are barely audible (goes from attack to release without reaching full volume) and smeared together.

[+] bonestormii_|4 years ago|reply
Yeah, articulation should be standardized in the midi specification. It's always a custom mapping to control it even when proper articulations are available. "Oh cool, custom mapping?!", you might say. Wrong. It sucks, because it tends to make old old scores utilizing articulation unusable because the mapping was stored in some obscure plugin configurations divided amongst many plugins.

It would be great if articulation messages were standardized, and then you could just expect them to be there, and if they are absent, the soundfont can simply fall back to the closest thing available. That kind of helpful logic is not possible with custom mappings.

[+] rutierut|4 years ago|reply
There are a lot of claims in this article about MIDI1.0 that are misleading at best, it makes it sound more limited & crude than it is. Still it's indeed very nice to see some improvements here, especially since some were transitioning to proprietary communication protocols over HID.
[+] dang|4 years ago|reply
Some past related threads:

MIDI 2.0 Specifications Available for Download - https://news.ycombinator.com/item?id=22411765 - Feb 2020 (35 comments)

MIDI 2.0, first major overhaul to music interface standard from 1983 - https://news.ycombinator.com/item?id=22180731 - Jan 2020 (105 comments)

Details about MIDI 2.0 - https://news.ycombinator.com/item?id=20007638 - May 2019 (147 comments)

MIDI 2.0 Prototyping announced - https://news.ycombinator.com/item?id=18946222 - Jan 2019 (195 comments)

[+] sillysaurusx|4 years ago|reply
I just wanted to say, the next and prev links on comments are a brilliant feature. Thanks!
[+] sharklazer|4 years ago|reply
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.

[+] m-hilgendorf|4 years ago|reply
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.

[+] jcal93|4 years ago|reply
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.
[+] jchw|4 years ago|reply
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.)

[+] iainctduncan|4 years ago|reply
It won't. It will make certain small elements of music making a little easier, but there's nothing in Midi 2.0 that will fundamentally change what we can or cannot do in a way that will be noticeable in music in a broader sense. Compared to something like the advent of cheap digital recording, VST plugins, of fast computers, midi 2.0 is a drop in the bucket.

That said, I'm definitely looking forward to having it reduce the number of hacky workarounds we currently deal with to get high resolution data in convenient forms. Honestly to anyone not deep into the weeds on this stuff it will be meaningless.

[+] elihu|4 years ago|reply
Per-note pitch bend is a big deal, and it could impact the kinds of music people use MIDI for. Right now, it's pretty awkward to use MIDI with controllers that aren't piano-like or to play music that isn't in twelve-tone equal temperament.

That said, I'm kind of pessimistic about MIDI 2.0's prospects. Maybe it'll be adopted by most of the manufacturers, but it's not looking like anyone is in any great hurry to start making compatible hardware.

There are also some problems that MIDI 2.0 just doesn't address (as far as I know), like the limitation of 128 notes per channel, or the difficulty of expressing a volume swell in a way that a synthesizer will play in a predictable way.

[+] IAmGraydon|4 years ago|reply
Yeah I mean the feature that matters most is high resolution MIDI CC so we can finally avoid stepping. It’s great, but long overdue and not really a game changer.
[+] musicale|4 years ago|reply
Exactly. Though with MPE we may see more controllers that support polyphonic expression. Personally I'm happy that ASM is making keyboards with polyphonic aftertouch.
[+] timc3|4 years ago|reply
You hit the nail 100% on the head there. I Couldn’t agree more with what you have said hence the comment and not just an upvote.
[+] prox|4 years ago|reply
Of all technologies, I believe MIDI has been the most plug and play experience for me. Plug a midi cable in, boot up a sequencer and you are good to go. Really interesting to see what can be done with MIDI 2.0
[+] wtfrmyinitials|4 years ago|reply
I was trying to write a program using midi last year and was surprised by the lack of any libraries to work with it. Then I looked up the spec and was able to get all the functionality I needed with 10 lines of code interacting with /dev/midi. Incredible how powerful such a simple interface is.
[+] em3rgent0rdr|4 years ago|reply
Midi can plug-and-play so easily because there is no handshaking. Every midi capable device has already agreed upon the 31,250 serial baudrate and 8-bit data + 1 stopbit format and the commands.

The only occasional problem I'll experience with midi is if I unplug before sending a note-off for a note, then that note might forever be stuck on.

[+] throw_m239339|4 years ago|reply
That's all good up until you try to synchronize different MIDI devices with their own sequencers. Even "voltage triggering" is more accurate...
[+] odiroot|4 years ago|reply
Never mind what new features will come, I hope it'll always be backwards compatible with MIDI 1.0. MIDI today is so universal and so easy to understand, even on the very low hardware level.
[+] SeanLuke|4 years ago|reply
I know that this article is meant for the general masses, but it's rather misinformed in nearly every sentence it utters regarding MIDI 1.0. That's a shame.

I'm pretty bummed out about MIDI 2.0's prospects. The protocol has been very slow to come out, and its design is ugly, overcomplex, lumbering, and kitchen sink. It is nothing like its predecessor. MIDI 1.0 was pushed by a single person with a small coterie of contributors, and has the design elegance and simplicity of such. But MIDI 2.0 has been wasting away for years in a large committee, and reeks of it.

MIDI has only a few, fairly easily dealt with problems:

- It's too slow and has a fixed rate.

- Its time sychronization mechanism is primitive.

- Its data model is too low resolution both in value and parameter space, and workarounds (NRPN etc.) unacceptably trade off speed to fix this. The model also does not define constraints, such as min/max values or categorical labels for values.

- Its parameters are global rather than per-note (resulting in workarounds like MPE).

- Its escape mechanism (Sysex) is too flexible and leaves too many nonstandard design choices to the manufacturer. Because the CC/NRPN data model is bad, manufacturers often have resorted to layering custom and proprietary protocols on top of sysex, many of which are very, very badly designed, and all of which are different from one another. Indeed, some manufacturers have lately treated their corner of MIDI Sysex as a trade secret, using non-documented protocols (ahem Arturia) or profoundly stupid and lazy sysex protocol designs (I'm looking at you, Roli).

This stuff is easy to fix. But 2.0 goes far further, dumping in two-way communication protocol options, device queries, ties to existing, non-peer-to-peer protocols (USB) and lots of data models that do not appear to be separable from the basic stuff. What a hairball. Will anyone want to implement this?

[+] romwell|4 years ago|reply
Yes to all of this. MPE is good enough.
[+] robbrown451|4 years ago|reply
I wonder when Firefox will support MIDI 2.0, since they still haven't supported MIDI 1.0. (chromium and other browser engines have had MIDI support since maybe 2014) https://bugzilla.mozilla.org/show_bug.cgi?id=836897

Yes, cool things can be done with MIDI in browser, some that can't easily be done outside of browsers (such as synchronizing and overlaying on top of 3rd party videos, such as from YouTube). Here's some of the stuff I've been working on, mostly targeted at my kid, but adults love it too:

https://www.youtube.com/watch?v=khU5A6Y1dk4

(this one doesn't play on youtube because contentId flags it, but the app itself overlays on 3rd party YouTube videos and it is not a problem) https://www.karmatics.com/video/pianoplydemo.mp4

https://www.youtube.com/watch?v=p1TcyDZiuyI

https://www.youtube.com/watch?v=Gj2rlytbDsY

[+] matchagaucho|4 years ago|reply
The article fundamentally speaks to how industry standards led to a proliferation of synthesizers and collaboration within the music industry.

The Metaverse, coincidentally, is at nearly the same crossroads as MIDI in the early 1980's.

Each vendor built their own hardware and defined their own protocols. When Roland open sourced the MPU-401 chipset and gave away the MIDI specs, the industry blossomed.

Anyway, a lot to learn from MIDI... if Meta can similarly align an industry around basic hardware, APIs, and formats.

[+] 999900000999|4 years ago|reply
The only issue I've noticed, and this might just be an iOS thing is devices would randomly disconnect, I know it's not good for my iPad but one day I found myself incessantly plugging in the adapter over and over again to try to get it to work. It's at the point where I'm tempted to go Bluetooth midi only when using my iPad from music Creation. Which prevents me from using my full size piano, first world problems
[+] romwell|4 years ago|reply
As long as it's 100% backwards compatible, including the 5-pin DIN connectors, I'd be on board. No 5-pin, no game.

More on this below.

----------------------

USB midi is one of the worst thing that happened to MIDI. If I have a synth with USB midi and a controller with USB midi, I can't connect them to each other, which is idiotic and frustrating.

The original MIDI spec had its drawbacks, but the biggest have been addressed by MPE.

As for latency, jitter, granularity — as a gigging musician and producer, I've never had any issue with it. It's good enough. And most of the music you hear today is a reflection of that.

What's not good, it's that some manufacturers are ditching the 5-pin MIDI jack for USB or Bluetooth. Thanks, nobody asked. Same for losing the THRU port.

Because what musicians love is setting up their computer on stage while everyone is waiting, right?

Bidirectionality with MIDI can be achived by replacing the dual 5-pin MIDI with the mini-DIN (yes, the same connector the old PS/2 mouse used). Yamaha Tenori-On and and Reface series do that (though again, nobody asked).

And the entire NRPN space of MIDI is unused because it's unstandardized. So simply agreeing on how MIDI 1.0 should be used would address most of the problems that MIDI 2.0 claims to solve.

That's what MPE does, by the way, and that's why it has been silently becoming the de-facto standard.

The examples I see in promotional videos show a computer talking to MIDI 2.0 devices. We've had enough of that. What made MIDI 1.0 work is the simplicity of device-to-device connectivity, regardless of what the devices are (and whether one of them is a PC).

Think of this magic: if I have just ONE type of cable, I can connect ANY device to ANY OTHER device.

That means my Yamaha MX-88 I bought new last year can talk to Korg Poly-800 made before I was born.

I could have bought the cable in the 80s or yesterday, it's the same cable.

What MIDI 1.0 gave people is less thinking about how to connect devices, and more about making music.

USB midi did the same thing for devices connected to a computer, at the expense of being usable in a setup that does not have a computer. That implicit assumption — that everything will involve a computer — was flawed.

WTF, I want to use my ROLI to play my Yamaha — and I can't, because ROLI is too "modern" to talk to any hardware synth made the same year.

I hope that MIDI 2.0 avoids this fuckery, but I can't tell yet. Bidirectionality looks sus.

My litmus test is: if a device doesn't come with a 5-pin MIDI jack while having space for it, it's a gimmick (Teenage Engineering being an exception, because they make up for it with analog control: my pocket operators sync with my Korg Monologue via pulse, and Korg syncs with Yamaha over 5-pin MIDI).

And if Korg Volca could do it, so can pretty much everything else (hint: don't put it on the side, put it on the front panel if you want that slim look).

MIDI 2.0 can be a huge success if you wouldn't be able to tell a MIDI 2.0 device from a MIDI 1.0 at a glance; i.e. same connectors, same interoperability. Then it would be truly an upgrade, a 2.0, and not "thing that works like MIDI in some cases, but have fun buying dongles to connect old equipment to new gear".

MPE works on that model; and connectors aside, any multitimbral device is MPE-compatible.

[+] dmoreno|4 years ago|reply
My hope is that they finish the MIDI 2.0 rtpmidi protocol, and that starts to be truly used in real hardware, not half used as current rtpmidi.

This would allow easy connectivity with very low latency over normal LAN, including switches, power over Ethernet...

Disclaimer: I created a rtpmidi implementation for linux https://github.com/davidmoreno/rtpmidid

[+] elihu|4 years ago|reply
> "MPE works on that model; and connectors aside, any multitimbral device is MPE-compatible."

Technically that's not true. MPE adds a feature where you can dedicate a channel as a sort of "multicast" channel where any CC you send there affects all the other channels shared by the same instrument. If the synth doesn't support that it won't work. But it's possible to implement fallbacks that just do the multicast less efficiently from the controller.

I completely agree on USB though. It's awful that I can't just plug a USB controller into a USB synth.

(If there was going to be something to replace the old 5-pin DIN cables my vote would be for CAN-bus. It supports faster speeds, bidirectional communication, and can go pretty long distances.)

[+] kall|4 years ago|reply
I generally agree but wouldn‘t be so dogmatic on the 5-pin.

I know some people consider 3.5mm to be the devil‘s plug, but as a eurorack player I don‘t. I feel like MIDI on 3.5, now that the polarity is standardized, is really helping the good, USB-less MIDI stay relevant.

[+] habosa|4 years ago|reply
This 100x. I am just getting into all of this hardware and it's so frustrating to need a computer in the mix just to get two pieces of otherwise wonderful single-purpose hardware to speak to each other.
[+] Rochus|4 years ago|reply
> As long as it's 100% backwards compatible, including the 5-pin DIN connectors, I'd be on board. No 5-pin, no game.

According to the specs which can be downloaded from midi.org there is no 5 pin DIN socket or 31kbit/s current loop anymore; the new Midi instead uses Ethernet and Wifi to connect "instruments". Apparently the protocol runs on UDP.

> As for latency, jitter, granularity ...

Well, maybe I play too fast or too many notes in a chord, but it happens quite often that I get an arpeggio instead of a chord.

[+] nitrogen|4 years ago|reply
If I have a synth with USB midi and a controller with USB midi, I can't connect them to each other, which is idiotic and frustrating.

Is there a universal MIDI router/multiplexer box with a whole bunch of USB and MIDI ports on it? If not, would there be a market for such a thing?

[+] zozbot234|4 years ago|reply
> USB midi is one of the worst thing that happened to MIDI. If I have a synth with USB midi and a controller with USB midi, I can't connect them to each other, which is idiotic and frustrating.

Isn't that what USB-C is for?

[+] snvzz|4 years ago|reply
>how will MIDI 2.0 change music

By breaking compatibility. Everything used to just work, now a layer of complication is added to the mix.

This is why we can't have nice things.

[+] supernovae|4 years ago|reply
MIDI 2.0 is going to have a tough road ahead of it to get any adoption.

MPE solved some expressiveness and didn't break the world...

[+] 112233|4 years ago|reply
What happened to OSC?
[+] spacechild1|4 years ago|reply
OSC hasn't really been designed as a replacement for MIDI, I think. It is really a generic data communication protocol. They only specified the syntax and omitted any semantics. As a consequence, each application has to specify their own OSC messages. And that's what digital mixing consoles, lighting consoles, DAWs like REAPER or computer music programs like SuperCollider do. There really is no common ground between how these applications use OSC.

To make OSC a suitable replacement for MIDI, you would have to come up with a set of OSC messages everyone can agree upon. That's not likely to happen...

[+] diskzero|4 years ago|reply
What happened, as in why isn't OSC "MIDI 2.0"?

The short story could be that the members of the MIDI Association chose to pursue their joint specification to be the next version of MIDI.

The actual story will have to be answered by someone who attended all of the various meetings that have occurred over the last three decades about what the MIDI 2.0 spec will be. I was only at a few.

[+] romwell|4 years ago|reply
The same thing that will happen to MIDI 2.0, I feel :D
[+] moomin|4 years ago|reply
I wouldn’t hold your breath on MIDI 2 guitar controllers being better than MIDI 1. The fundamental problem is pitch resolution and that isn’t really addressed by having a better protocol for representing pitch and intonation.
[+] rkagerer|4 years ago|reply
My biggest problem with MIDI is the latency & jitter introduced by USB adapters (many computers these days lack a dedicated sound card or even the space for one). Does the new spec do anything about that?
[+] em3rgent0rdr|4 years ago|reply
And to be pedantic, USB is not officially part of the MIDI spec, so that problem introduced by USB adapters isn't really a problem with MIDI per se.

If you really want to interface MIDI with a computer in a fashion consistent with the original MIDI specs, then you can use an actual Serial port at MIDI's 31,250 baud rate, which is possible to do on a Raspberry Pi for instance (or on a computer which you could set your baud rate to that). Then you can get interrupts precisely when the MIDI notes arrive.

[+] bitwize|4 years ago|reply
If you want MIDI without latency or jitter, you pretty much need an old Atari ST. USB isn't the only source of latency (and I believe MIDI over USB runs in a special mode that minimizes latency).
[+] throw_m239339|4 years ago|reply
No, because most MIDI capable devices couldn't be bothered to implement the first version of the spec correctly even today.