Is MIDI obsolete?

[JonHodgson]

People seem to think that having a new standard would suddenly mean that all your old gear can't be used, which is completely wrong.

Any new system would need to be upwardly compatible. This is not difficult, because MIDI is so simple, all its messages could be covered by a subset of the new standard. For example if controllers are all 16 bit, it's not a problem to drop 9 of those and send the top 7 to a MIDI device. Note information? No problem there, and for more complex things like mixers you'd ideally want some kind of automatic mapping, but that's not difficult either, it's along the lines of

IF you receive a message for Mixer Channel 5, Bass EQ 0 THEN send MIDI controller 72 on port 3 channel 4

The physical interface is hardly a problem.

[aciddose]

abstraction.

[farlukar]

People seem to think that having a new standard would suddenly mean that all your old gear can't be used, which is completely wrong.

Any new system would need to be upwardly compatible.

This "new standard" is already 10 years old

[JonHodgson]

People seem to think that having a new standard would suddenly mean that all your old gear can't be used, which is completely wrong.

Any new system would need to be upwardly compatible.

This "new standard" is already 10 years old

The firewall here blocks that, so I can't check, but as I recall wasn't XMIDI that strange trinary system which was intended to be physically backward compatible as well as in the messages?

If so then it was too messy in my opinion, the physical interface is the least of our worries since you can so easily build a box which converts from say firewire to a MIDI socket, with enough processing power to do any mapping required.

ZIPI was far more interesting in my opinion, but it wasn't successful either. Perhaps it wasn't enough of an improvement compared to the additional requirements in hardware.

The thing is that more and more units are built which have an interface with far higher bandwidth than the physical MIDI connection (be it firewire or USB), and they have more than enough processing power to handle a more versatile and complete protocol... all that's needed is a software update. When our physical transports are a minimum of 1.2 Mbit, and we have high speed 32 bit processors in just about everything, being limited to a message protocol devised according to the limitations of a 31.25kb physical interface and 2 MHz 8 bit processors is really rather silly.

[4damind]

Obsolete? mmh, some years ago as I tested Midi-sampledump to my Sy99, I hoped Midi was obsolete since years
But today... most modern hardware has USB. Midi is an easy protocol and very flexible, with a quick interface from the hardware/instrument to others there is no problem. I hope there are in the future something like a standard "Midi over USB" and "Audio over USB" protocol, so that all hardware can communicate together, as quick a possible.

The protocol isnt obsolete, but the interfaces with the slow transferrates.

[JonHodgson]

Obsolete? mmh, some years ago as I tested Midi-sampledump to my Sy99, I hoped Midi was obsolete since years
But today... most modern hardware has USB. Midi is an easy protocol and very flexible, with a quick interface from the hardware/instrument to others there is no problem. I hope there are in the future something like a standard "Midi over USB" and "Audio over USB" protocol, so that all hardware can communicate together, as quick a possible.

The protocol isnt obsolete, but the interfaces with the slow transferrates.

Sorry, but I disagree... partly...

Now that we are freed from the limitations of the physical interface, the protocol is ridiculously limited. Let's take controllers for example, you have a control surface, you have a synth, you then have to set up your control surface to send various controller numbers and/or set up your synth to respond to them. You then get a new synth and have to go through it all again.

A good protocol would be bi-directional, plug your control surface into your synth, and up pop all your parameters, all correctly labeled. Plug them both into your sequencer, and the same thing happens.

And the whole thing of 127 bit controllers and then the mess of RPNs and NRPNs is just a stupid thing to have to put up with now. Have you seen what a bodge they are? They are a solution to a problem we no longer need to have.

[Sascha Franck]

I must admit, I do hate the midi timing issue. It would be so cool to have all your hardware running together in sample accurate sync. But this isnt happening with midi - the best interfaces are accurate to around 1ms (and thats bullshit).

Yeah, timing could be an issue sometimes. 1ms (if things will really go as low as that) shouldn't be all that noticeable from a timing point of view though. Heck, most A/D converters produce latencies higher than that.

But then, as ew pointed out, MIDI is a serial protocol, so a higher amount of data throughput will defenitely raise latencies in a rather unpredictable way.
Hm, yet, USB is serial a well, and it's able to deal with high data throughput in a way better fashion than MIDI

In addition, let's not forget that MIDI signals don't travel well through cables longer than, say, 7-8 metres.

Anyways, I've yet to see the musician who would easily spot the difference in timing between, say, a routing MIDI keyboard (local off) > computer > MIDI keyboards internal synth and just playing the internal synth in local on mode.
As said, with higher throughput (lots of channels being used) this might become easy - for a single channel stream of notes and some occasional CC or pitchbend, I doubt many of us would easily spot the difference. I certainly wouldn't, and usually I'm rather anal about things such as timing.

I did study the midi protocol, but I forget much of it. Is there not a way to string together to words and have 14bit accuracy for CC's? Im sure we learned about this on some Roland synth, so you could sweep the filter with no steps at high rez.

I think that's what RPN/NRPN parameters are for: 14 bit accuracy. Not sure what the limitations/restrictions are, but I think there's a good reason why they aren't all that commonly used.

Well, they're a true PITA to deal with, as usually they have to be sent one after each other, which sometimes requires quite some editing. Give me a synth with internal parameter smoothing any day over that - so I can just use a single CC for parameter sweeps (most VSTis these days are doing fine).
I really hope I'll never have to deal with NRPNs and the likes again in all my life (and preferably take the MSBs and LSBs away from me as well...).

How else would I connect my keyboard to my PC and let Cubase tell it what to play without using a MIDI Interface?

Theoretically, modern electronic connections could use another protocol as they're delivering a WAY higher bandwidth.
Quite a lot of standalone synths aiming at live useage (stage pianos, V-Drums, whatever) are allready using another protocol with better internal timing and parameter resolution, plus they're even offering some things that you can't reproduce all that easily using MIDI. Look at how brush swirls or hihat pedal things are dealt with on those V-Drums - still pretty tough to accurately reproduce them using whatever MIDI expander, be it hard- or software.

Such things *could* be realised easily over USB, firewire, network or whatever connections, it's just that for best compatibility this would require a new, widely accepted protocol to be established.

The OSC thing is looking quite interesting, but then, as soon as my MIDI data is inside the computer, it usually isn't a problem anymore, as properly programmed virtual instruments will be sample accurate on playback, will offer MIDI learn modes or so and will have parameter smoothing, should rapid sweeps be my desire.
The problem still arises when you actually input data or have to use external synths.
So, to actually overcome the limitations of MIDI, we'd need new hardware controllers, communicating via a faster protocol.

OK, here's the deal:
I WANNA DO SLIDES LIKE IN FRUITYLOOPS! fcukin' damnit! Why can't somebody just develop a new interface that will allow me to DO SLIDES LIKE IN FRUITYLOOPS?! Yeesh...

This is no limitation of the MIDI protocol per se.
It usually is a limitation happening in three stages:
- The way your host is dealing with MIDI messages.
- The way your synth/expander/VSTi is dealing with MIDI messages.
- The way you understand MIDI.
And probably, in addition:
- The way the MIDI standard is documented.

No offense meant, but hey, 99% of folks dealing with sequencers and what not don't even know that CC 11 (Expression) is used pretty much widely as "relative volume" - at least that's what the GM standard is using it for.
So you'll find loads of people automating their CC 7 for volume sweeps and the likes, thus complicating overall level adjustments, while using CC 11 would just do the same (well, it defaults to a value of 127, but that shouldn't be much of a deal) while allowing you to still use CC 7 for overall mixing control.

The same goes for about any "special" parameter beyond notes, modulation, volume and probably pitchbend (uhm, a lot of people don't even seem to know that pitchbend is no regular CC...).

So, in your case, to get the slides you want, you'd have to have a synth understanding portamento and a host properly dealing with CC messages.
Most hosts admittedly aren't exactly brilliant at that and there's not all that much synths allowing for CC routing to portamento time - even if the latter is a part of the GM standard (CC 65 = portamento time).
However, assuming my synth would understand those portamento messages (or I could reroute them), I could set up a pretty much FL-alike editor scenario in Logic - yes, with individual pan (CC 10), volume (or expression, CC 11), slide (portamento, CC 65), cutoff (CC 74) and resonance (CC 71) controls - the numbers in brackets showing that even the GM standard is supposed to support all that.

In addition, usually there's a helluva lot "free" MIDI CCs left. So it's all about the allready mentioned things: Proper sequencer implementation and proper synth implementation (regarding MIDI assignments and internal parameter smoothing to avoid stepping effects).

Mind, MIDI is still evolving. There is a transport spec for MIDI Over Firewire. There's a new "high definition" HD-MIDI proposal on the table.

Any links for that?


Anyways, from my personal experience, timing issues aside (which can become *very* critical, depending on your needs and setup), most people I know haven't even barely scratched the surface of what *could* be possible with good old MIDI, if only implementations (in both hosts and synths) and documentations were available in a nice, transparent fashion. Unfortunately both doesn't seem to be the case rather often...

[4damind]

A good protocol would be bi-directional, plug your control surface into your synth, and up pop all your parameters, all correctly labeled. Plug them both into your sequencer, and the same thing happens.
...

That is true. I forget about the parameter, preset and others. I don't know if Midi has a "only parametername" request? It would be no problem if the host can make a request to synchronize to the synth. But I think there is the problem the slow pysical interface today for that usage... Have Highspeed-Midi and you can recieve a "parameter-bulk" in millisecounds.

[Sascha Franck]

True, proper bidirectionality would be *quite* something, with controllers actually displaying parameter names and what not, regardless which one you're using. Right now, this is a major PITA and usually only working if you're using one of the few compliant controllers and sequencers (such as Cubase/Logic with a Mackie implementation or whatever...).