For anyone wondering about MIDI's limitations, here's a post by Roger Linn going into it a bit: https://www.rogerlinndesign.com/support/why-expression
> So why is this expressive touch control important? Because under skilled hands, the ability to capture subtle musical gestures enables more interesting and expressive solo performances than a MIDI keyboard's on/off switches. Consider a guitarist's string bends, a violinist's skillful vibrato, or a wind player's subtle breath control, all of which can't be authentically replicated on a MIDI keyboard.
>In my view, the limitations of MIDI keyboards have resulted in electronically-generated music being used largely for background music
We're starting to see several MPE-capable instruments hit the market. I have a pre-order out for the Osmose keyboard, which has per-key pressure and per-key (horizontal) pitch bend. If pre-release reviews are to be believed, it does a very good job capturing things like "a guitarist's string bends, [or] a violinist's skillful vibrato".
Someone needs to tell Roger Linn about Raves i think.
Sorry, you must be holding it wrong. It is useful and flexible enough for countless applications. It was defined in the 80s and still used universally today, so objectively the opposite of useless and terrible. It is limited though.
It also (contrary to popular belief) supports far more finegrained granularity in parameters than 256 levels. Also MPE uses existing MIDI protocol (1.0) capabilities to map the polyphonic messages.
Isn't that its intended use?
I don't understand how you could use it for other categories of instruments unless you mean syncing their clocks?
A midi guitar seems fairly non-sensical to me (they exist but aren't perfect) so how could we stardardise around something that's likely to completely change in 5-10 years?
What features were you hoping for in 2.0?
...we have been saying the same in the past 3 decades.
No industrial player is large enough to push this change. We need some very extensive backward compatible hardware and software to make this possible.
The ubiquity of MIDI and its piano-centric design has meant that it's been a very uphill battle trying to do any kind of electronic music that isn't plain 12-edo piano music. That's a shame. We've lost out on a lot of interesting music that could have happened if it was just a little easier.
MPE at least has made it reasonably possible for things like the Linnstrument to exist and be commercially successful.
Unless your entire setup is composed only of Minilogues all configured in the same tuning settings, your electronic instruments will be out of tune with each other. Plug in an old yamaha because you like the sound? Now everything is out of tune. This isn't supposed to happen in a MIDI workflow.
It would be much better to be able to specify tuning system in the midi messages itself, so that any instrument, hardware, software, or whatever, knows to make it's Ds 6 cents flat so your whole electronic orchestra can be in Werckmeister tuning together, instead of just the one minilogue.
- Control Change msgs are largely a wasteland of non supported features
- messages are not uniform size, so you can’t read a midi file backwards for instance
- the file format, usb format, uart format, and bluetooth format are all related but not fully compatible. Especially the file format which has meta messages that cannot be sent over bluetooth or uart, etc.
- sysex messages are not packetized in the original spec, needing delay to send large messages
- NRPN and RPN messages are another wasteland
- same with system real-time, song changes, bank changes, smpte, all needless complexity no one uses.
- the file format needs a chunk length written in the header, which is annoying to keep rewriting when recording continuously
- the file format needs an “end of track” msg that needs to be rewritten again and again when recording to disk
It’s fine for NoteOn and NoteOff. Most of the rest of it is pretty mediocre imo.
- no way to play a unison without resorting to multiple channels - communication is one-way, so no standard way to query what CCs the synth actually supports - tuning table support wasn't part of the original spec (MTS exists but most synths don't implement it) - poly aftertouch exists but it's hard to actually use it effectively due to how it's implemented in keyboards and how the protocol is designed - 128 notes per channel isn't enough for some instruments without resorting to MPE - MPE addresses an important use case but breaks some MIDI abstractions (users have to know about "zones" instead of "channels") - it's possible to lose a "note-off" resulting in a stuck note - 31.25 kbps is slow by modern standards (USB is faster, but then you're stuck with short cables and the "what if neither or both devices are a USB host" problem)
On top of that, I think it's a bad sign that midi.org requires you to login to download the MIDI 1.0 spec. What are they trying to accomplish by making it harder than it needs to be to just read a 40-year-old specification?
I think it may be a good time for a new protocol that isn't based on the same fundamental abstractions as MIDI. Device compatibility isn't necessarily even that big a problem as long as cheap conversion devices to translate between protocols exist (though of course MIDI devices would be limited to what it's possible to express in MIDI).
Instead of note on / note off, I'm imagining a bidirectional protocol where the controller explicitly allocates voice circuits, explicitly tunes them to a particular pitch, and then either triggers envelope generators or takes manual control of the envelope.
For a physical layer I think CAN bus could be a pretty good option. It's meant for low-latency real-time tasks, it's supported by a lot of microcontrollers, the standard speed is 1mbps, and cable length can be very long at that speed (40 meters).
Sounds way more complicated.
What makes midi great is how simple Note On and Note Off are.
At the end of the day, piano keyboards are just buttons. It’s no different than a qwerty keyboard. Getting the note data should be trivial.
The simplicity of the Note On Note Off api is the only reason midi still exists despite the rest of it.
Well, sort of. Consider though that a polyphonic synthesizer typically has to internally go to the trouble of allocating a free voice circuit, tuning it to some pitch, and triggering the envelope. What I'm suggesting is making that more explicit in the protocol. In some ways it's simpler because it's closer to how the synthesizer actually works.
> What makes midi great is how simple Note On and Note Off are.
It is nice that you can get a working MIDI controller or synth up and running with very little effort, but if a thing is too simple then it misses a bunch of nuance and becomes an impediment to more sophisticated use cases.
> At the end of the day, piano keyboards are just buttons. It’s no different than a qwerty keyboard. Getting the note data should be trivial.
Technically, that's not true. Most MIDI controllers use a double switch mechanism, where the time elapsed between activating the first and second switch tells you have fast the key was pressed. That gets sent as velocity in the NOTE-ON message.
Sending high-resulotion pitch data should be fairly trivial as well, it's just that we don't have a standard widely-supported way to do it. (MPE seems to be the current best option.)
midi is only bad if you try to abuse it for actual digital audio.
A) The full protocol seems to be proprietary to some degree. To access the official specs, I believe you need to be a paying member. There are other sources, but this is not an ideal state of affairs.
B) The current protocol seems to be composed of dozens of random accretions on top of the original protocol. Various extensions are only sporadically supported, so in effect you typically don't have any more capability than the simplest version of the protocol anyway.
B) There's a new binary protocol and a new pseduo JSON-rpc framework on top. If you read the free documents you would not come away with this conclusion.
We're a long way removed from sending 7-out-of-8 bit messages along 3 feet of cable with optocouplers doing our decoding. It's like a weekend of work to write a MIDI 2.0 decoder for a massive amount of benefit. And it's transport agnostic.
> a new pseduo JSON-rpc framework
Is this supposed to make me feel better? The primary reason MIDI 1.0 is still in active use is basically that it did not do anything like this.
It's hard to see what you want: You can't be complaining about lack of physical interfaces not present on your hardware (the additional specs for Midi over USB, RTPMidi, TRS plugs and the 3.3v 5pin din) so are you sad that your drum machine doesn't play bagpipes when you switch to program #110 (General Midi) or that a Juno 106 doesn't magically add reverb when you crank up controller #91 (the suggestions for CC mappings) or perhaps you are trying to send samples to a Yamaha DX7 using the DLS standard?
You are not really missing out though. I.e. you can still use the broil setting on your toaster oven even if your microwave doesn't support that. no-one is forcing you to use the lowest common denominator on every device.
This is not correct at all. There are tons of active extensions on top of the midi 1.0 protocol, even outside of sysex. It's not like they just wrote it all at once and then left it alone. These are the accretions I am referring to. Examples:
MIDI Time Code (MTC) (MMA-001 / RP-004 / RP-008) General MIDI System Level 1 (GM1) (MMA-007 / RP-003) General MIDI 2 1.2 (GM2) (RP-024/RP-036/RP-037/RP-045) File Reference System Exclusive Message (CA-018) Sample Dump Size, Rate and Name Extensions (CA-019) MIDI Tuning Updated Specification (CA-020/CA-021/RP-020) Controller Destination Setting (CA-022) Key-Based Instrument Controllers (CA-023) Global Parameter Control (CA-024) Master Fine/Coarse Tuning (CA-025) Modulation Depth Range RPN (CA-026) Extension 00-01 to File Reference Sysex Message (CA-028) CC #88 High Resolution Velocity Prefix (CA-031) Response to Data Inc/Dec Controllers (RP-018) Sound Controller Defaults (RP-021) Redefinition of RPN 01/02 (RP-022) Renaming of CC91 and CC93 (RP-023) Three Dimensional Sound Controllers (RP-049) MIDI Polyphonic Expression 1.0 (RP-053)
you originally wrote: > ... Various extensions are only sporadically supported, so in effect you typically don't have any more capability than the simplest version of the protocol anyway.
This is just not true - every device have different capabilities and you control them with what ever midi messages the device responds to. Sometimes they follow those standards and other times the don't. I.e. I can control the Reverb level on a Yamaha AN1X through CC#91 (which is a General Midi defined controller mapping for Effect 1 level). If I send CC#91 to an Arturia MicroFreak it will change ARP/SEQ rate. Sure it's a little annoying that I have to read the midi implementation list for each of my devices, but I'm not going to give up and never control those settings just because the don't align with the published extensions.
I'm not a composer but I imagine .sib and PDFs
I thought midi was more intended for live messaging between different instruments/controllers
The dude replying to you with “Sibelius” apparently doesn’t understand that, like all other DAWs and notation programs…Sibelius uses MIDI, because of course it does.
It sounds like MIDI is meeting your expectations, but people who have different requirements might disagree.
As an example, consider notating this in proper, exact just intonation:
https://www.youtube.com/watch?v=I49bj-X7fH0&t=1s
There are probably some composition programs that can do this, but MIDI is more of a hindrance to that task than a help.
MPE is kind of a kludge, but it works decently well and it absolutely addresses a real use case. For a certain kind of user it was a welcome addition to the MIDI spec.
The MPE presets I’ve messed with with some Roli kit have been fun.
MIDI is fine for some instruments and for controlling few high level parameters. If you want to make music though, you'd go with a DAW instead which can start with MIDI on some tracks, but otherwise works with waveforms instead.
There's also a difference between when you only compose, want to hear the idea put together and give musicians the sheets, and when you want to create the end result fully on your computer.
There are some really great guitar sample packs out there, I particularly love the Impact Soundworks Shreddage series, but just look at how much they had to mangle MIDI to make it feasible, with NINE (9) sections of the keyboard dedicated to mode switches, and chopping up the velocity space into five different articulation modes, and they still can't model unison bends which are a staple of classic rock guitar: https://www.youtube.com/watch?v=P2h9AmL2BhI
edit: actually after double-checking, they do support unison bends, but it's a special CC parameter that you have to turn up to do the technique and then turn back down when you don't want it anymore, pretty hacky. The point is, you can't use MIDI to actually play these instruments like real guitars live, even though these sample packs can produce realistic guitar sounds, you need to do butt-tons of midi programming in ways that MIDI wasn't intended to be used in order to make it sound mostly right to the point where it's probably easier to just learn to play the instrument than put in the extreme effort of meticulously programming all this faff.
Lets hear the special needs you have.