Workarounds, sure, but I wouldn't call it a nasty hack to simply interpolate between the discrete MIDI steps.
> There are various hacks to send 14-bit control change messages
NRPN is part of the standard and allows 14-bit control messages, so no hacking required.
> MIDI is also built around the western scale, with no real accommodation for other tuning systems.
There's the MIDI Tuning Standard since 1992, so there is a standardized accommodation for other tuning systems, and a bunch of synthesizers that implement it. Just not part of the MIDI 1.0 standard itself.
> OpenSoundControl addressed these issues and more besides, but it lacks widespread support because it was developed unilaterally rather than as an industry-wide collaboration.
IMO OSC probably lacks widespread support exactly because it doesn't specifically address most of these things. It's a protocol for sending timestamped and namespaced data over a network, and anything much more specific than that is just a matter of ad-hoc convention. It solves getting high precision data to devices in a timely manner, but it doesn't address the issue of getting a client to play a note.
In general I think that MIDI 1.0 just being tolerated is a great way to summarize the situation, and I'm glad that actual MIDI 2.0 implementations are seemingly around the corner.
"MIDI Polyphonic Expression" and is a new MIDI standard created by us, ROLI, Apple, Moog, Haken Audio, Bitwig and others for communicating over MIDI between MPE controllers ... The principal reason for MPE is to get around a limitation of MIDI: Pitch Bend and Control Change messages must apply to all notes on the channel. This prevents polyphonic pitch bends and polyphonic Y-axis control (which uses Control Change messages) over a single MIDI channel. MPE solves this problem by sending each note's messages on a separate MIDI channel, rotating through a defined block of channels. Here's a brief summary of MPE: http://www.rogerlinndesign.com/mpe.html
Today there seem to be work arounds, not that a new midi version would not work better, however.
Then there’s the fact that many manufactures promise MPE support in their devices, but rarely in 1.0 firmwares... you either ship with it or wait 6 months for either a crummy implementation or a statement from the manufacturer walking back support. It sounds like a non-trivial software implementation task, especially on devices with resource starved I/O processors
Back in the day I made loads of custom switch boxes and so on to allow whatever bizarre system I thought was a good idea into a reality - in fact I only got the last one out of my studio about 3 weeks ago when I finally removed the 19" rack I've had in there for the last 20+ years. The ubiquity and compatibility of MIDI has been one of the reasons that it's still around today. Forgetting that would be a huge mistake, IMO.
If you wanted to switch to something common, I'd personally say Ethernet (or something "normal", and a specified transport over Ethernet). Handles the distances and data rates more than fine, parts to implement it are widely available, it's already used more and more in stage and recording setups, so specialized components are available too. In the audio sector, standards to distribute precise clocks are around, one could maybe reuse those to get it past P2P connections (although that kind of gear is still kind of expensive right now). Still quite a step up in complexity though...
MIDI is the lingua franca of music equipment. It controls mixing consoles and effects units, it synchronises music to lighting, it provides timecode and controls recorders. You might not use that stuff, but it's an essential part of the spec that is used every day by professional musicians and engineers.
I think they're saying one should use rugged USB cables for live performance, rather than a typical consumer-grade cable.
If MIDI2 can work with USB-C in a way that devices can be linked, instantly, because the USB-C circuitry they use can speak just enough USB to verify the connection is between two MIDI devices, then I will be more than happy to give my MIDI cables away and never bother with them again.
And yeah of course a stage or studio setup will still need them for the foreseeable future, it's not like decades of midi instruments vanish overnight. But you'll also start seeing USB cables thrown into the mix, and eventually you might not see MIDI cables at all in 20, 30 years.
It has to start somewhere.
USB wasn't designed for this use case, and it is a very, very common problem.
Certainly, UBS in general can't be used for this purpose, but if there's true industry buy-in for MIDI over USB then it's not hard to imagine more and more USB hardware will get made that can compensate for that problem. For instance, I wouldn't imagine laptops to get isolated USB, but a shiny new post-MIDI-2 audio interface sure would.
In that environment, isolation is a constant concern. Connections that are inherently isolated make fault-finding far more straightforward and obviate the need for external isolation boxes.
For even a simple USB audio interface setup connected to a single audio source I would recommend isolation and balanced audio cables.
There are a lot of potential technologies that could improve upon the antiquated MIDI cable standard, but USB is actually worse in a lot of ways.
CAN bus might be a good option; it's fast enough, and is already available on a lot of cheap microcontrollers. I haven't worked with it, though; maybe there's a shortcoming I'm not aware of.
I agree that there are plenty of things to improve on the old midi spec, but I think for a lot of people the issues are irrelevant - while physical midi is 31k, most people I encounter now use multiple soft synths in their DAWs, and aren't even aware of the original spec and speed of midi (unlike back in the day with multiple synths chained off a single midi output on an atari ST where it was definitely an issue).
I remember zipi, which promised similar useful changes and came to nothing - I think for the vast majority of people midi doesn't get in the way of their work.
Did mlan also promise similar improvements?
sounds like C
The typical MIDI 'instruction' requires 3 bytes. So, 1000 non-intense instructions per second. Not good enough for intense controller mods, but if the played 'instruments' do most of the work, that's over 80 ips (notes e.g.) for each of 12 voices. (Also that's 3125 bytes per MIDI input, of which you're welcome to use many.)
Perfectly adequate most of the time ... and one reason that the original, genius design lasted this long.
NOT to say that it isn't insanely great to hear this news.
And considering one of those bits is used for status, it’s effectively 7 bits worth of resolution (128 discrete values is... not great for anything but maybe western scale note pitch values).
This is very much a "Falsehoods Programmers Believe About Names" type of situation - what western engineers perceive as an insignificant edge case is a constant frustration for many non-western musicians. The answer to the question "How do I play music from my own culture using electronic instruments?" should not be "Well, it's complicated...". Support for non-western scales should not be a clumsy, optional part of the spec.
https://www.midi.org/articles/microtuning-and-alternative-in...
Yes, it could be better but I don’t just tolerate it.
The probability this is true for any system in use (software, natural language, tax code, home appliance...) asymptotically approaches 1 with its age in years.
Sure, it's old and outdated, but it does the job.
OK, what I'm going to say is not constructive, but, boy, how I hate this type of comments. Where were you 40 years ago? Why did you not prevent it from being terrible? What did you do to replace it with something better?
Yes, it may be "suboptimal" by the 2019 "standards", but back then, I'm pretty sure, people put a lot of thought in to it and tried to make it as good as possible. Just because it looks childish on the current hardware does not make it "pretty terrible".
EDIT: It's almost like complaining that 555 is absolute rubbish comparing to 8266 that can do sooo much more, and why just did they not come up with something better back then.
I'm not saying that they should have come up with something better. MIDI was an incredible breakthrough in 1983, but it was designed in 1983. That's a very, very long time in technology. We've known about and dealt with the shortcomings of MIDI for decades, but it's difficult to replace a deeply-entrenched standard. MIDI has been pushed as far as possible without breaking backwards-compatibility, but it is now long overdue for the industry to move in unison and create something fit for the 21st century.
Imagine if you dealt with lots of devices on a daily basis that had a 33kbaud serial interface. Would that kind of annoy you? Would you say "this archaic serial format is just great!". No, you'd be kind of cheesed off that you were stuck with it.
MIDI 2.0 looks great. It's a really big deal for the electronic music industry. You can only usefully say why it's a big deal if you acknowledge all of the crummy, annoying parts of MIDI 1.0.
And I'm not a fan of this kind, either.
Yes, it might be unfair to poke holes in a standard from the 80s from a 2019 perspective, but it was GP's assertion that the MIDI standard was unsuitable to last as long as it did without an update. _That_ is what is being criticised as pretty terrible, and that's fairly clear from what GP wrote.
The first major issue is simply the lack of bandwidth. The physical layer operates at 3125 bytes per second, which just isn't enough for anything more than a single instrument with relatively sparse control data. MIDI devices can ostensibly be daisy-chained, but that's a really dumb thing to do because you get horrible timing problems. Back when we still used a lot of hardware synthesisers, it was the norm to have a large multi-port MIDI interface connected to your computer, providing one interface per instrument. That still doesn't solve your problems if you have a multitimbral module with lots of polyphony - if you start sending control channel messages, the timing of your note on/off messages will fall apart.
The second major issue is the lack of resolution. MIDI is an 8-bit standard, which is generally acceptable for velocity but grossly inadequate for most control channel messages. There are some pretty nasty workarounds being used to avoid zipper noise when you adjust a control parameter; this is most commonly an issue when sweeping a resonant filter. There are various hacks to send 14-bit control change messages, but they're non-standard aside from velocity and pitch bend.
MIDI is also built around the western scale, with no real accommodation for other tuning systems. We're forced to use the crude bodge of sending a note on message immediately followed by a pitch bend message; MIDI doesn't support per-note pitch bend, so you can't have polyphony and microtimbrality on the same channel. This is a fairly niche issue in the west, but it's a showstopper in a lot of other musical traditions.
OpenSoundControl addressed these issues and more besides, but it lacks widespread support because it was developed unilaterally rather than as an industry-wide collaboration. The spec is very powerful, but it just isn't very nice to work with. It's exciting to see that the MMA have a number of big players involved with the development of MIDI 2.0. We've been talking about fixing MIDI for a long time, but it seems like there's finally the traction to get a new standard widely adopted.