While my setup has been growing and more and more midi related issues has surfaced, I sometimes wonder why there are only 16 midi channels available. Why is this the case? Was it implemented as a industry standard due to hardware limitations back in the day? Is there any reason why we can’t have, for example, 128 midi channels to choose from today?
Probably because few people use more than 16 instruments simultaneously. also you can set up in other ways using those 16 channels, for example an MPC can send channels 1-16 and channels 1b-16b come out of the second output. That’s on an MPC1000 but other MPCs and sequencers may have more midi outs. I’m not 100% sure of the real answer of why it’s industry standard. I’m definitely interested to hear the robot orchestra you’ve got going on if you’re using upwards of 16 synths at a time though
1 Like
It made sense back in the days as a way to keep a good balance between implementation cost and bandwidth.
2 Likes
Yeah, im no where near to having that much skills and gear. I own an MPC1000 myself and like the fact that there are more ports to choose from. I recently discovered midi patchbays that solves a lot of the issues (after tips from this forum 
) The example of wanting to have more unique midi channels to choose from, actually came from when starting to map a BCR2000 to controll my Octatrack. Since the Octatrack can use up all 16 midi channels when maxed out I run in to trouble when using the BCR which has a lot of presets to choose from. So If I make a preset that uses all 16 midi channels and have it hooked up so that it can controll all my gear via a patch bay, it is hard to make it so that the BCR does not interfere with gear that is not intended to be effected at certain times. So I dreamed a little about having the OT using midi channels 1-16, the MPC midi channels 17-32, my TX81Z midi channels 33-40 and so on. That way there would be no risk for interference.
you could use 16 synths off course but also 1 synth can play multitiple midi channels. The use of playing with patterns also plays a role I think & layout of the keyboard especially with drummachine. I also think the more midi channels ther would be the more complex things would become like with midicodes & midimessages like FO-FF,sysex, because of the limitations alfabet, i guess
Yes it is because of bandwidth, midi is a serial protocol which means that only 1 piece of information can be sent at a time, even using 16 channels is pushing it, once you have more than a few notes playing timing starts to be noticably affected.
3 Likes
Considering it was 1982 that midi debuted and is still in use today 35 years later is quite remarkable, I can’t think of any other protocols which have lasted as long. There is no reason that midi can’t be updated, and in fact it has a few times, but all the while we require backwards compatibility with legacy gear it can’t practically be changed too much.
3 Likes
because for many midi messages (not all) , 2 bytes are used… first byte for type+channel, second for value, so that first byte used 4 bits for type (e.g. noteon, off, cc, poly pressure), and 4 bits (=16) for channel…
… and we have to retain backwards compatibility (for now 
)
for usb its a bit better, as you can also have 16 ‘ports’ each with 16 channels, so that’s 256 channels.
4 Likes
I can imagine Would Midi messages on channels above 16 be more demanding byte wise and so on?
Ah I see! Thought it could be something like that 
I don’t know where I read it. But hasn’t there been discussions about something like midi 2.0? Perhaps it could be made backwards compatible somehow…
Ah, what the hell. Lemme give the full answer.
Back in the days when MIDI was created, microcontrollers that were still reasonably affordable were all 8-bit and fairly slow.
Because of this, MIDI data is all in 8-bit numbers, or bytes, because that’s the only thing the hardware at that time could reasonably deal with. These bytes are sent one after each other at a speed of 31250 bit per second which is an exact division of 1 MHz, which in turn is the speed at which many of those microprocessors ran.
A MIDI message consists of a status byte followed by one or two data bytes. The status byte defines the type of message (Note On, Program Change, etc), while the data bytes contains the parameter values for that message (note number and velocity, patch number, etc.).
The receiving device needs to be able to tell status bytes and data bytes apart. This is done by having the status bytes always start with a “1” bit and data bytes always start with a “0” bit. This leaves 7 bits for actual data, which is why the parameter range 0-127 (or 1-128) is so common.
Because they didn’t want to add an additional byte for the channel, the channel number is packed into the status byte. Using 16 channels leaves you with 8 different values (128/16=8) that can be used to differentiate between the types of messages that are being sent.
They actually ended up defining 7 different channel messages (Note On, Note Off, Key Pressure, Control Change/Channel Mode, Program Change, Channel Pressure, and Pitch Bend) so that they could use the last remaining bit for status bytes that identify so-called System Common Messages that don’t need a channel number.
Of course they could have used a separate byte for the channel, which would have given us 128 MIDI channels on a single connection. Or they could have limited the number of channels to 8 or 4, giving us more different channel messages.
The downside of adding a byte would have been more latency because the speed at which the bytes could be sent was limited by the hardware that was available.
This bandwidth limitation also meant that having a larger number of channels wouldn’t have made much sense, because you wouldn’t have been able to send messages over that many channels at the same time without introducing noticeable latency for the ones that are at the back of the line (since they all need to be sent one after the other).
I think the original designers made good choices given the technological limitation of the day.
15 Likes
There have been a number of additions to the midi spec over its lifetime, the most commonly known of which is general midi which came along in the early 90’s, and of course Elektron’s turbo midi which is backwards compatible with legacy gear but not at turbo speeds for obvious reasons, I don’t think many other manufacturers adopted turbo midi though, although a few do, midi 2.0 has been in development for a few years now, not too sure if there has been a final decision made on it as I have not kept up to date in it, but I do know the mma have recently announced significant enhancements.
3 bits, actually. The first bit is used to differentiate between status and data bytes.
2 Likes
Wow thank you for the thorough explanation. It certainly seems like they did a good choice since it is still what is used today. Are you updated on if there are plans for an upgraded version and what some changes would be likely to be implemented in that case?
https://www.midi.org/ There you go! You can join their list and get notified about news relating to midi.
2 Likes
One of the most important things that they’ve added very recently is MIDI-CI which stands for “Capability Inquiry”. This opens up the way to a future version of MIDI while remaining fully backwards compatible. You can read more about this here and here.
3 Likes
This certainly looks interesting from their Twitter. Anyone have the time to explain what we are looking at here 
?
1 Like
Turbo MIDI is cool, but very much not part of the official MIDI specifications. A downside of Turbo MIDI is that it is bi-directional; for the connection to work both devices need to have both their IN and OUT port hooked up to each other.
2 Likes
Yeah, it worked out well. Over USB you almost always connect to a single hardware device and inside a DAW you connect to a single plug-in, and in that case 16 channels are plenty for almost all use-cases.
16 channels also worked out well for MPE since most people aren’t able to play more than 10 notes at the same time with expression.