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.
I find it difficult to believe that someone with even a passing knowledge what MIDI does would have this opinion. Most of the variables are only 7 bits of resolution which produces jarring jumps when you try to adjust parameters in real time.
I remember taking a college class 20 years ago where we talked about the deficiencies of MIDI and what MIDI 2.0 should look like. It's been 20 years since that conversation and it's mind boggling to me that MIDI is only getting updated now.
A different way to eliminate jumps is simply to low-pass filter the values on the receiver, and read out values from the filter at whatever rate your synthesizer engine can handle. The precision of most controls does not matter that much; you just want to eliminate zipper noise, and this does that.
(Of course there are some controls which need the extra resolution. Filter cutoff comes to mind… even 10 bits I've found limiting. Strangely, even though MIDI 1.1 specifies some 14-bit CCs, filter cutoff is not one of these.)
That presumes a continuous information stream being sampled. But the sample-depth problem affects discrete notes, too—it's pretty easy to notice how coarse-grained the quiet end of variation is on a MIDI keyboard or drum controller's attack pulse.
In a musical mix, -20 dB down, plus "off", is all you need; anything turned down more than about 20 dB relative to everything else disappears.
+/- 20 dB of cut and boost spread into 127 bits is ridiculously good resolution.
There's no room to use small changes in volume for expressiveness at the low end of the volume scale, since attacks/sustains/release shape is more quantized. So if your piece has fff and ppp in it (which is probably a full 40dB range) the ppp part will sound super flat while the fff part might sound great.
But forget about playing and releasing notes. Say you're triggering a MIDI drum machine and a synth. Sounds like violins have a slow "attack" - that is, you don't go instantly from "no sound" to "full sound", but ramp up over a short interval. Imagine a violinist that has to start moving their bow, or a trumpeter that has to start blowing. It doesn't matter if you send a synthesizer a set of "note on" messages saying "play a middle C major chord" for violin sounds and they don't all get there simultaneously, because it was going to take them all a little bit to start playing anyway. Drums are a different story. If you expect a kick and hi-hat to play at exactly the same time, you don't have that many milliseconds between their starts before a normal human listener can start to really notice it.
So, the worst case scenario is that you'd have a piece of sequenced music that plays two drums, a piano chord, a bass line, and a violin chord at the same time. This is were sound engineers start getting hyper nitpicky about stringing the equipment together so that:
- The two drums fire off in adjacent time slices so that they sound as simultaneous as possible.
- The piano notes come next, from lowest (because if it's a sampled sound, low notes will be played back more slowly and therefore have a slower attack) to highest.
- The bass sound comes next because those don't usually have a super aggressive attack.
- 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.
The worst case scenario is:
- One drum fires off.
- The rest of the instruments fire off in reverse order of their attacks, like high piano, bass, high violin; medium piano, medium violin; low piano, low violin.
- The other drum fires off.
Because MIDI is so glacially slow compared to every other protocol commonly used, it's going to sound absolutely terrible.
MIDI is amazing in so many way, but it has some very severe technical limitations by modern standards. I can't believe it's taken this long for a replacement to come along.
(Note that if you stand with your guitar 5 meters from your 4x12 stack, you're hearing a 15 ms delay due to the speed of sound.)
Also, the physical layer of MIDI could simply be extended into higher baud rates while all else stays the same.
I can't remember the last time I used a serial line to an embedded system in the last 15 years that wasn't pegged to 115 kbps. Bit rate is a relatively trivial parameter in serial communication; it doesn't give rise to a full blown different protocol.
115 kbps is almost four times faster than MIDI's 31250. Plain serial communication can go even faster. The current-loop style signaling in MIDI is robust against noise and good for distance. 400 kbps MIDI seems quite realistic.
This would just be used for multiplexed traffic, like sequencer to synth; no need for it from an individual instrument or controller.
Rounding this off to 0.002 s and taking speed of sound to be 340 m/s, we can work out that sound travels 68 cm in that time.
So if you're positioned next to a drum kit such that the snare drum is somehow 70 cm farther from your face, and the drummer hits both at exactly the same time (down to a small fraction of a millisecond), you will hear the snare drum 2 ms later than the high hat.
You're assuming that all of the MIDI events in the entire show are multiplexed onto a single serial data link. That means all the controllers and instruments are daisy-chained, in which case your latencies may be actually worse than you imagine because any piece of gear that has store-and-forward pass through (receives and re-transmits MIDI messages) adds latency.
The obvious way to avoid all that is to have a star topology: have the events flowing over separate cables from the controllers to the the capturing MIDI host, or from the host sequencer out to instruments. Have little or no daisy chaining going on.
Now if you have lots of MIDI streams concentrating in some host and it wants to send all of them to another piece of gear (like a synth, to play them), then maybe yes, the regular MIDI serial link might not be the best. I'm sure we can solve that problem without redesigning MIDI.
> I can't believe it's taken this long for a replacement to come along.
Almost forty years tells you that this is a solution in search of a problem. Industries don't stick with forty-year-old solutions, unless they really are more than good enough.
True, some of it is conservatism coming from the musicians: lots of people have gear from the 1980-s that speaks MIDI, using it on a daily basis.
Isn't MIDI... digital? What do ground loops matter as long as the signal decodes?
Or do you mean that they'll put current into the analogue signal chain?
IMHO, the correct response to that is to do all hybrid analogue+digital signal processing in the digital domain with opto-isolated pre-amp ADCs, no?
For instance, rack-mounted synthesizer with analog outputs going to a PA.
> 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.
Or do you need High Speed (480Mbps)?
The reason why we don't do that is acoustic and electrical coupling. Sound is AC, and because it is alternating we have to deal with impedance matching. air to physical objects actually has a poor impedance mismatch because of the difference in density. Electrically with pickups, when one system has a poor impedance match to another system some really interesting effects can occur. When you overload a downstream device sometimes you can produce interesting interference that just happens to produce harmonics that are musically pleasing to the ear (3rds, 4ths, 5ths). Electrical guitar amps are a great example of this; you can actually design a tube amplifier to produce even or odd order harmonics by the electrical structure of the amp.
It's the "less than perfect" analog devices and their complex interactions that make what musicians to refer to as "tone".
Fortunately there is actually an alternative: it's called balanced transmission. The standard for audio is unbalanced unfortunately. But essentially you get the best of both worlds: noise rejection from third-party sources yet analog transmission and coupling. Ironically most digital transmissions eventually travel over an analog balance transmission.
One of these is ethernet (RTP midi), which should not have this problems. Or Bluetooth, or WiFi (very bad latency).
Or USB or DIN 5.
I don’t understand why this matters at all. The engineers who made 1.0 had different sets of constraints that we no longer have.
Now days we shove gigabits a second over cheap twisted pair wire. MIDI could do a lot more on modern or even decade old hardware...
Yes, and when you listen to your PC's "line out", you can hear the unwanted effects of all that sort of thing.
USB in its most common form has shared ground.
I just switched to a bus-powered USB-C (Arrow) audio interface and have picked up a nasty ground loop/dirty power noise problem in the process. Current setup is a MacBook with the Arrow directly plugged in, and MacBook powered by a second thunderbolt 3 connection to an OWC Tb3 dock, and I am assuming if I power the Mac with its dedicated power supply the noise issue will go away, but if it doesn’t... well, I don’t know what else I could do to fix it.
In the past I’ve solved all similar issues by using a powered USB hub between the problem devices and laptop.
Wouldn't basic economics suggest that talent vacuum would lead to most talented musicians making good money? -- And I'd argue the opposite is the case - there's a lot more musical talent than the world "needs" (and thus is willing to pay for). Therefore most musicians are poor (and many with additional talents stop being musicians). -- Or did you mean the "talent vacuum" in a different way?
There's no reason you couldn't make an optically isolated USB hub. With USB 2 it would be trivial. USB 3 is harder but I doubt you need that for MIDI.
I mean Beethoven did some incredible shit without even MIDI 1.0, I’m not sure that’s a sensible line of reasoning.
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.
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
"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.
Much better article:
"MIDI Poliphonic Expression" (MPE) essentially involves only playing one note per channel, which means that things like pitch-bend (which apply to every note on a given channel) can therefore be applied per note. The major downside of doing this with traditional MIDI is you're still limited to 16 channels, but with MPE it then also means you're limited to 16 notes.
Also, that man looks a lot like Garth Hudson... https://pbs.twimg.com/media/DjtfCgOUwAA6K7o.jpg:small
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.
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.
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.
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.
I believe there are messages that add another 7 bits to velocity, and aftertouch can represent key position, but I haven't used a MIDI-enabled acoustic myself to know if those are adequate.
Also, support for Sostenuto pedal (i.e., the "middle" pedal) is spotty and frequently doesn't get captured or preserved on MIDI piano controllers and sequencers even if a MIDI'd piano records it.
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?
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.
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.
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.
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.
This makes no sense. That would also imply a way to discover (and name, and probably provide semantics for) all parameters. That's a huge ask if MIDI (even MIDI 2.0) is the only communication protocol available.
Yes, the first 4 of your list are common. The first one is covered by the core MIDI spec. The 2nd and 3rd have no standard msg, but your complaint seems to be about the contents of the message, which is no business of the requestor. The 4th assumes "patch RAM", which cannot be assumed, as you note, and that seems correct to me.
Why? It's highly standard. About 90% of the synthesizers I've written patch editors for provide exactly this facility. In fact some (PreenFM2, Korg Microsampler, Futursonus Parva) provide only this facility.
> The first one is covered by the core MIDI spec.
Actually it's not. Program Change only works for 128 patches. If a synth has more than 128 (and many do), they must rely optionally on Bank Select, but their definitions of "banks" vary because a bank is not a formally defined concept. Some rationally treat banks as divisions of the patches. Others treat banks as media choices: cards versus RAM versus ROM. Some require that Bank Select be immediately before Program Change with nothing in-between; others do not. Some ignore banks entirely and instead define a "Program Change Table" of 128 slots pointing to arbitrary patches in memory, and then Program Change indicates which patch slot to use.
And there are several major synthesizers (Yamaha TX81Z and DX11 are famous examples) where Program Change is in fact broken and requires unusual workaround hacks. Further, most synths require a program change prior to a patch load: but others (notably the Oberheim Matrix 6 and 1000) require a program change after a patch load. It's a mess.
Back in the 90's, when things like "MIDI Librarians" were common (and widely used), each new device needed to be added to the MIDI Librarian's code to deal with the specifics.
I think you may have misread what I had said. I didn't say that patches had to be the same format or content -- that would be insane.
What I mean is that, if they have to reformat their internal struct to conform to a standard, they don't have the processing power to do this munging. Not that they'd care, as you have noted elsewhere.
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.
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.
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.
Leaded gasoline was successful for decades too, but there comes a time to take things to the next level.
MIDI 1.0 was successful for 30+ years because of its simplicity, so I'm not sure what you are disagreeing with. Building a MIDI payload is extremely simple and serious manufacturers will document their MIDI implementation in public documents.
What part of the MIDI spec did you have hard time with when developing software using the MIDI 1.0 protocol?
Your comment about gasoline has absolutely nothing to do with MIDI.
Allocating memory (by asking the OS) in a realtime context is a no-no. This means guessing the maximum size of a sysex ahead of time or breaking RT programming rules.
The other tricky issue is the way MIDI 1.0 defines the transmission of the LSB and MSB for 14 bit messages. They got it backwards, requiring the receiver to use a timer. Might have been sensible for baked-in-h/w MIDI gear, not so great for general purpose computing.
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.
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.
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.
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.
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?
As long as you don't transmit anything else. When you have 16 channels with many note and controller messages, latency and asynchronicity between channels can become noticeable.
However that approach didn't work when I wanted to send 16 channels to a single (non USB) multi instrument sound device like my trusty JV-1080. It became an excuse to buy more synths! :-)
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?
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.
Even in highly time-aware percussionists, sensitivity to timing is way below the timing delays that MIDI causes (e.g. with note smearing in a chord).
The next roadblock on the way to truly concurrent chords would probably be controller readout. I know nothing about how those are typically implemented, but I strongly suspect sequential readout.
Changing MIDI to have "defined latency" is a fundamental re-engineering of the entire protocol.
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.
> Is this something that's worth potentially getting rid of something I love for new capabilities that may or may not be compelling?
The actual spec sheet is yet to be released, but this is a really great article about it.