MIDI's issues in a notation context are twofold: non-standardization of controls for e.g. choosing articulations for string instruments, and an inability to communicate future information if known to the MIDI producer - say, for instance, knowledge that this Note On event is the beginning of a phrase that will last for 2 measures, as known to notation software.
There's a real way in which MIDI solved for communicating trigger events over the wire, but was not extensible enough to allow for further backwards-compatible standardization that would let it communicate music over the wire. By contrast, the web evolved from communicating hypertext to sending entire application environments and executable code over the same protocols. The web was born later, to be sure, but in an age where an Arduino can execute JavaScript, I wish we were looking to much more extensible modes of communication as inspiration for what can be done with interoperable musical devices.
I agree with you in general, but I think it's important to note that the web has evolved in a forwards incompatible manner. You can't hook up an older device/web browser to the modern web and have it work with modern web sites. In many cases (depending on how old) it doesn't even degrade gracefully.
On the other hand, you can hook up a 40 year old MIDI keyboard to a brand new iPhone via MIDI and it just works.
To be pedantic, a forty year old MIDI device will probably have a pretty poor MIDI implementation by the standards of five years later…e.g. the DX7’s MIDI is notoriously limited (and it is only 39 years old).
I see your comment has been down voted, likely due to pedantry, but I wanted to let you know I appreciated it. One of the things I love about this site is the tremendous depth of otherwise obscure knowledge.
Not being the smartest person in the room is what has always brought me back.
To me, the downvotes suggest the way the community is changing.
I suspect I could have been just as pedantic without acknowledging it - and perhaps even aggressively argumentative - and been more appreciated by my readers. Probably leaving off the equanimious point-getting sentence would have improved reception.
Anyway, MIDI was a ChatGPT of my youth and because I was gear aware when the DX7 showed up in music stores, now that I have empty nest adult money I have considered buying one and hence done some research. A fantasy largely abandoned after having bought and sold a handful of cheaper and lighter late 80's Yamaha MIDI instruments.
For what it's worth, there is a somewhat rare third party upgrade board for the DX7's MIDI ports, and if the maximum you want to do is send and receive Note On/Off on a single channel a stock DX7 will be good enough. It just doesn't do most of what people expect MIDI to do even though what it does is pretty amazing for the price when it was released.
Technically you could just employ CC to send extra info, say send CC with number representing how long the note will be, or the modulation type the note should get. We already have MPE abusing standard a bit to have per-note bending and such.
The biggest problem in MIDI is IMO the fact there was no possible option for any standard negotiation between devices.
You had MIDI IN and OUT, and at any time one or both could be connected to instrument/controller, you didn't knew where you were outputting it, and you didn't knew who send you control messages.
That utter simplicity had benefits from interfacing perspective but it also made it impossible to expand the standard easily.
There was no option for "MIDI 1.1" that would say improve some stuff but still had option to send MIDI "1.0" compatible signal if it detected that other side doesn't talk it.
There was also no option for simple "tell me what CC 85 does on you" so every mapping between devices had to be done by hand or by loading someone's profile.
It kinda had to be what it is, it was introduced in 1983 where extra transistors were pretty fucking expensive so simplicity of the protocol was huge benefit, I'm pretty sure simple MIDI keyboard could be implemented even with a bunch of logic chips without much problem.
> no possible option for any standard negotiation between devices.
While I agree for ease of designed use, I also think that’s one of the fantastic features of MIDI, because it makes it possible to use participating devices in novel ways, never anticipated by their manufacturers.
For example, I sometimes use note pressure messages (a.k.a. polyphonic aftertouch) as a second set of 127 control change messages, rather than their documented design intent.
Right but you wouldn't need that hack in the first place in MIDI2.0
It does look pretty overcomplicated, but then the variety of use cases might be excusing it.
Also the fact it has some kind of negotiation doesn't preclude doing clever things with it, just the fact you don't need to rename knobs differently for every single device you connect
> Right but you wouldn't need that hack in the first place in MIDI2.0
Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx).
My kind of hacks (and numerous others) will hopefully continue to extend the useful life of older MIDI capable hardware and lessen the burden of landfills a tiny bit.
I’ve been very relieved and excited to read, that MIDI 2.0 is supposed to be very backwards compatible, so hopefully I can use my old hardware with ultra modern software for a long time.
> Also the fact it has some kind of negotiation doesn't preclude doing clever things with it.
In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases.
If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former.
>Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx).
I should probably dig that MIDI dashboard project out of pile of abandonded projects someday, once upon a time I bought cheapo midi matrix controller (Midiplus smartpad) then kinda... not really using it for much so I mapped which MIDI command lights what light and wanted to make a dashboard of various stuff out of it...
I do like how trivial 1.0 is; implementing it on a microcontroller has been a breeze.
>> Also the fact it has some kind of negotiation doesn't preclude doing clever things with it.
>In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases.
> If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former.
That does worry me a bit with 2.0, it is absolutely "and the kitchen sink" of protocols and considering how even 1.0 implementations can be janky we might see a bunch of pretty badly designed 2.0 implementations
If MIDI is like serial port, is MIDI 2.0 USB or Bluetooth? If USB then it's about right. If it's Bluetooth it's over-engineered and will never get off the ground properly.
I used to play with hardware MIDI devices - at first without a PC (just a Q80 sequencer as the "hub") and then with a PC.
MIDI isn't technically tied to a medium, but the only notion of addressing are MIDI channels (at least the classic v1 from the 80s) - you can target messages to any channel 1-16. It's up to you to set your devices to listen on the right channels. For example: If you have a keyboard set to transmit on channel 5, and two modules listening on channel 5, they'll both play when you press a key on your keyboard.
Classic MIDI with the DIN plugs was a RS-232 wire protocol - devices typically had an IN, OUT and often a THRU port to forward all received MIDIs (some forwarded everything out of the OUT port). Latency was a problem with the older devices, but there were "MIDI hubs" that fixed that, and when computers started getting MIDI hardware (Atari ST had it built-in, and ISA MIDI cards for the PC were a thing), it got better.
So as long as devices are connected via some serial-like communication method and can forward to each other, MIDI will work over it if all the devices involved can use it. I'm not too familiar with everything Bluetooth but I know that Bluetooth virtual serial/COM ports are a thing. MIDI speeds are low (33Kbit/sec). Classic MIDI will work just fine over that, without any additional engineering, as long as all nodes agree to send and receive MIDI over it.
Even Hayes AT commands (the closest thing to a standard at the scale of MIDI) required knowing baud rate, data bits, stop bits, and parity bits to establish a serial connection.
For me, Bluetooth works much better than MIDI because there’s no setting channels or sending all-notes-off because something hung up.
I didn’t see the comparison because it didn’t make sense to me. YMMV.
>I didn’t see the comparison because it didn’t make sense to me. YMMV.
The comparison was between the compexity level. Also between MIDI and MIDI 2.0: whether 2.0 would be similar to its current serial MIDI 1.0 implementation, USB, or BT complexity wise.
>For me, Bluetooth works much better than MIDI because there’s no setting channels or sending all-notes-off because something hung up.
That must be a joke, right? Because BT is 10 times worse in this regard, getting the user to manually forcefully do a connect/reconnect cycle, not connecting and not knowing why, dropping the connection, and so on.
MIDI once it's connected, it pretty much just works: which is why they do live shows with midi for 3+ decades, whereas they wouldn't touch BT for live show with a 100000000 long pole, even if latency wasn't an issue...
Those suggestions were literally unimaginable when MIDI was invented. Samplers barely had enough memory for a single sample, never mind GB of multisamples with countless articulation options. And semantic messaging - for phrases, etc - is a whole other level of complexity which has barely been researched, never mind implemented.
MIDI 1.0's failings are much simpler - limited resolution, limited channels, and limited support for polyphonic expression.
MIDI 2.0 has addressed all of those, but it's a bureaucratic monster of a protocol and I suspect it's not going to be popular.
We could really have done with a MIDI 1.5 which kept the same message types but made them 16-bit instead of 8-bit, and also added some extra poly-start and poly-controller features. That would have been enough to open a whole new world of expression without adding a lot of extra complexity.
I generally agree with most of your points, although I'd prefer to call it "limitations".
But even with those limitations, MIDI 1.0 has been used in numerous practical applications that have transcended the original use case concepts. From GM to MCU to MPE and many other things people have done at smaller scale or even just in their own custom setups.
Sure, those are "hacks", but especially on this site, I'd consider that worthy of praise, rather than ridicule.
To this day, thanks to MIDI 1.0, I can and do cobble very different pieces of hardware and software together to effectively create a highly individualized and therefore creativity boosting music making environment.
> MIDI 2.0 has addressed all of those, but it's a bureaucratic monster of a protocol and I suspect it's not going to be popular. -- We could really have done with a MIDI 1.5 ...
Yeah - MIDI 2.0 gives me a a vibe somewhat analogous to IPv6. But it's early days, so I'll wait how it plays out ...
You could get away from poly-anything with an essentially unlimited number of channels. Just use one channel per note, and banks like you currently use channels
I haven't had time to watch that video (though I will), but that sounds to me like complaining that the USB HID standard lacks proper support for ametric poetry. It's... not for that. Given a standard for how instruments work, MIDI's a reasonably simple event structure to represent them.
But the space of "what can you do with an 'instrument' to make music" is immense, and not feasibly susceptible to enumeration in a protocol like this. Music is art, and almost without exception every great musician ends up doing something that can't be represented by the algorithmic conventions of her ancestors.
MuseScore has the disadvantage of trying to live in this weird world of "typeset music", which has (for centuries) tried really hard to pretend that this disconnect doesn't exist. But it does, and it's not MIDI's fault any more than it is the fault of whoever invented the drum roll or pizzicato strings or anything else that didn't have a pre-existing notation.
Quite frankly MIDI isn't even MuseScore's biggest problem. Just look over the shoulder at any teenager playing with Garage Band with a big cacophany of effects and then ask "how do you put that in MuseScore". You can't, and you never will, and... that's probably a good thing.
The video isn't complaining about MIDI. It's just saying that MIDI isn't suitable for MuseScore's specific use case (playing orchestral scores through virtual instruments), and since VST instruments use MIDI as an interface, that problem wasn't immediately solvable. (Their eventual solution was implementing an alternative protocol and a plugin compatible with it.)
>But the space of "what can you do with an 'instrument' to make music" is immense
And the space of "what you can do expression-wise with very commonly used VST and sample libraries and notation packages" is hardly vast, and could very well be covered with MIDI if it has some more very basic capabilities.
It doesn't need to cover all the space (like how to express a musical saw performance), and nobody asks for this.
They ask for very common problems, everyone in the notation, sountrack, etc. field has, and that sequencers already solve - but in ad-hoc and non-standard ways, or ways that require too much manual intervention.
Common people, it's not like a 40 years old, pre computer music format, is the holy grail, and anybody criticizing it for lack of certain features needed today (today? Huh, expressive mode switch in sample VSTs has been a thing for 2+ decades) is akin to implying "USB lacks support for ametric poetry."
The typeset stuff was invented way before midi tho.
Just that MIDI was really invented for electronic instruments and, well, most of them were notes generated by pressing keys and maybe a modulation bar or joystick. Hell, arguably you still could transfer a lot of those modulations via CC commands but you'd have to standarise on which exact CC change corresponds to what instrument's technique.
That being said MIDI 1.0 clearly has a bunch of pain points (low resolution, no bidi communication making auto-config hard etc.) that are getting fixed in 2.0 but that just slowly started, so 1.0 is there to stay for a long time still.
> The typeset stuff was invented way before midi tho.
To be clear: that was the point. Typeset music notation has struggled to keep up with the physical expression of music[1] for hundreds and hundreds of years. There's nothing new about this problem, and it has nothing to do with MIDI.
[1] And MIDI is just another such expression in this context. MIDI is absolutely not an attempt to reproduce typeset music, it's designed to capture electronic instrument behavior.
The context here is not whether MIDI is a notation protocol or good for notating purposes, but about using MIDI to play the music in a notation app.
And the problem is that MIDI can't transmit and take advantage of the extra information a notation program has access to about the piece.
That's a problem with MIDI 1.0 EVEN outside a notation context. The limitations under notation program use of MIDI to play orchestral music, are also limitations of MIDI itself for things that would be very handy to have under many more contexts.
Standard MIDI sequencers for example, can't send messages about "playing mode" with semantic purpose, and resort to hacks (sending a simultaneous out-of-range MIDI note with your actual MIDI notes to signal a specific expression like pizzicato to a VST sample player), each done in its own ad-hoc ways (including CC, custom notes, abusing channels, and so on), and requiring ad-hoc mapping for every new VST, even for common shared attributes.
Because MIDI is commonly used in a notation context, and its limitations in that context are very commonly encountered by users, I would say a discussion about those limitations is very relevant and interesting.
> ...an inability to communicate future information if known to the MIDI producer...
The video notes that MIDI just wasn't designed for this purpose. It was designed as a standard messaging protocol facilitating communication between the different RTOS's used in synthesisers. The fact that it became a standard format for digital musical notation was probably just an afterthought, albeit a pretty good one. I couldn't watch the whole video, however there are always MIDI control codes which can be used for the kind of meta-information they're talking about, like specifying Staccato, or Tremolo.
And we already know, as those are the hacks we use and have used for years. They're still limiting tho for the intended purpose.
And if you're not using CCs/Sysex in an ad-hoc way, e.g. if you can get VST vendors to agree on some semantics for those, then you've just built a new protocol layer on top of MIDI, only you did it as a kludge, with whatever was available as a "safety net for unknown stuff" from 40 years ago, and not a proper design...
The most glaring one is that there is no way to encode rests, trills and other common meta data. Obviously, MIDI was meant for performance, not as a binary form to encode sheetmusic. There are some tricky ways in which you can augment MIDI though, for instance through creative use of the text fields.
To clarify, Musescore doesn't use midi to store notation, it's used to send note information to VSTs for real time playback of the score. The new protocol sends the whole score in advance so better phrasing can be calculated.
That's pretty much the conclusion the video makes. The context here is playing scores with VST instruments, which use MIDI as an interface. The solution they found was to implement a new interface suitable to their needs and an orchestral plugin compatible with that interface.
They're not trying to "piggyback on MIDI to store sheet music".
They are trying to use MIDI to play the sheet music, with their built-in sample player, and with third party orchestral VSTs, but with less information loss about expressiveness...
I wish midi was used for more things. Like I wish it was easy to map a dj controller to Final Cut Pro using midi. Or to studio one for photo editing. I don’t know how to do that right now.
Why limit yourself to Emacs, even if it might be the best desktop solution around? With Linux, Jack/PipeWire and https://github.com/eras/midihidi you can use your MIDI device with any app!
Granted it doesn't do chord detection.
It might actually have some "real" use cases: you could run an Amiga/C64/etc emulator, and a tracker within that, and then use this (with a proper keymap) to give it MIDI input. I didn't yet provide the ability to customize the keymaps, other than direct to source, though.. Pull requests welcome.
Not bad, but completely skips over the piano-centric nature of MIDI and the ways in which this has hobbled musical creativity for 4 decades (despite the rest of MIDI expanding it). The good parts of MIDI are ... OK, the bad parts are terrible. The best thing about it is really just about the only bit of technology the audio tech world ever managed to agree upon that was license free and at least adequate for some important tasks.
Ever since MIDI, every audio tech company has been convinced that its technology was going to be the next MIDI, and that the licensing fees from it would the ticket to an island of their own. E.g. check the state of audio-over-IP. You can almost hear people saying "I mean, imagine how much [ EDIT: Roland ] & Sequential could have made if they had licensed this!"
Synthesizers are musical instruments, which means they have a control part and a sound generating part. Because they are electronic, synthesizers can decouple these to a greater degree than acoustic instruments. That's why you can play any MIDI-controllable synth using a Yamaha EWI (a wind-driven controller) or a touchpad or a capacitative sensing service or a Haaken Continuum or or the pads on an Ableton Live surface or, yes, a MIDI keyboard.
Pianos are a very specific type of instrument in that they have fixed pitches (compared with any non-fretted string instrument, the tuba or the human voice). MIDI has many assumptions built into it that are derived from the way pianos work, which means that using it in contexts where you want the sort of control not possible on a piano is ... challenging. One obvious example is playing something in a way closer to what you can do on a guitar: MIDI has no real way of representing the sorts of control a guitar player has access to. That said, people have tried, and the best systems are quite good, although they tend to subvert MIDI semantics and just use the syntax of the protocol.
You've got different ways of adding expression to your playing with a synthesizer, not least of which being the traditional design of having a roughly coffee-table sized control panel covered in knobs.
Why limit yourself to trying to make it work like a guitar or a saxophone? The Yamaha EWI is a lot of fun to play, but I don't really see what it adds. You can add a bit of expression to relatively crappy samples, or to some unconvincing physical modelling synthesis of a woodwind instrument, but it's never going to fool anyone. You can use it to drive other parameters on a more "conventional" (by which I mean, creating artificial sounds rather than attempting to emulate acoustic instruments) synthesizer, I guess, but how much does that really help?
I would just like to point out that an EWI can in no way reproduce a real woodwind instrument. That's because woodwinds rely to varying degrees on vocal tract resonance and other properties of the airstream. I occasionally think about how an EEG-like array of electrodes around the throat could reproduce this but lack expertise in understanding how that might happen or if it was even possible. Anyway it makes the EWI experience really disapointing for me compared to playing a real saxophone especially the big grunt that articulating and intonating a baritone sax can produce, and the totally hammed up in your face emotionality possible on the soprano sax.
128 position CCs really hurt you when you want to tune something requiring exact value like filter to specific frequency. Some expanded to the hack of using 2 CC values to control one parameter but that's hit and miss.
Per-note modulation is only slowly getting there and severely sub-optimal (MPE is using a channel per note, cutting down number of devices you can drive from single MIDI port significantly).
Now I would say "hobbled" is overstatement, but it definitely have annoying parts that we have to deal with for decades now.
On top of that there are the usability issues, uni-directionality and simple protocol made it easy to make peripherals in the 80's but nowadays it's liability, because simple thing like "ask the device what CC it accepts and what they are named" is impossible in standard
No, you just need to widdle the knob till it is in range you want. If knob have too little detents you can't widdle it close enough to what you want. Granted, 14 bit CC is near enough but support in implementations is kinda spotty, and, well, it does eat twice as much CC.
Shove it into a synth that have a bunch of oscillators, filters, LFOs and effects [1] and you'd probably be forced to downgrade few of those parameters back to 7 bit
The Juno 106 has something like a semitone and a third, and no-one complains about its cutoff control being "steppy". Indeed, everyone holds it up as a paragon of smooth and progressive response.
There's actually a very clever reason for this, and if you study the circuit diagram and the voice card firmware you'll see just how clever it is.
That's the problem. If you want to make something that isn't piano like, you run right into a brick wall -- there's no way to send the note information you want to send in a way that's understood by any random MIDI synth. That makes it much more difficult to be successful.
Recently expressive instrument makers have settled on MPE as a workaround. That works, but it's kind of kludgy and isn't widely supported. You can also use an MPE-like approach on synths that don't explicitly support it as long as they're multitimbral.
Unfortunately there's a lot of amazing synths out there that aren't multitimbral.
Recent controllers that use MPE include the Linnstrument, the Roli Seaboard, the Haken Continuum, the Expressive E Osmose, and the NuRad wind controller.
There's no reason we couldn't have had violin-style synths, for example -- continuously changing volume and pitch as the note plays, for example.
Or synth woodwinds that encoded not just fixed pitches (from the keys), but continuously changing airflow and breathiness.
You can come up with examples for pretty much every instrument, really. Imagine what you could accomplish with a synth guitar that allowed you to bend pitches.
If MIDI had supported features like that, we may very well have seen an explosion in creativity of different types of synthesizers, beyond just digital pianos and drum kits.
Fortunately we might actually see that now, with MIDI 2.0 [1]. A quote:
> This should mean music played on MIDI 2.0 instruments will feel more analog, and make it possible for non-keyboard instruments to work better with MIDI. Historically, guitar, violin, and trumpet players have had to learn play keys in order to better translate their work through MIDI. Now, hopefully, they will be able to play their instrument of choice as an input into MIDI-compatible recording software.
Well yes, there are, the sensors for wind instruments or bowed string instruments are really hard to get right.
Never mind bowing, look at plucked string instruments - there aren't any really successful guitar synths that are actually playable to any real degree. The old Roland analogues in the 80s did the best job using a hexaphonic pickup and six PLLs to track the string frequency but they still didn't track well on lower notes, which is why Pat Metheny plays so far up the neck.
One of the reasons for this, I imagine, is the piano-centric nature of a lot of (amateur) music since 1800 or so. In small settings, a single woodwind or even a violin isn't all that useful. When you're targeting amateur musicians (a vastly larger group than professionals), basing yourself off a piano keyboard is a good bet as most of them will at least be familiar with it.
MIDI having been at "version 1.0" for 40 years is kind of a fib. Sure, the MIDI association never changed the number, but MIDI has undergone numerous revisions since 1.0 was established, including: LSB+MSB CC values, NRPN and RPN, General MIDI definitions, MIDI Show Control, MIDI Machine Control, MIDI Timecode, MIDI Tuning Standard, three different iterations of MIDI file formats, MPE, and so on. Even the guidelines for the hardware layer have changed from isolated DIN-5 to include USB, Bluetooth, and other transports. Really the only thing that hasn't changed is the basic byte encoding.
The current "1.0 Specification", circa 1995, is document version 4.2.
Fun fact: several computer games in the late 80s used MIDI to support cross computer multiplayer. At the time Ethernet/LAN cards on home PCs were rare, but if you played games you mostly likely had a sound card/MIDI card!
Crazy that I missed that. Neighbours had an Atari ST and a friend would sometimes come with his MOOG synthesizer and we'd hook it to the ST but we didn't know about MIDI hacks to play multiplayer games.
Now by default these home computers often had two joystick ports and to be able to play I-don't-remember-which-game we hacked some additional dual-port thinggy on a little PCB we'd hook into the ST's parallel port. This allowed us to play four players at the same time, each with our own joystick, on a single ST / monitor.
Very cool. Makes sense too. At it's heart, it's an event signaler. Doesn't necessarily have to be music based which is the case for lights and other stage production gadgets.
MIDI is still an amazingly simple, yet useful encoding. To think its been around since 1982 is astounding. I'm excited to see what MIDI 2.0 really brings and if its truly worth the added complexity.
The 1.0 encoding is incredibly simple and to have gone 40 years (and still going), with many many devices being compatible with the protocol, is something that should absolutely be celebrated.
Here's to 2.0 being just as long lived and successful, presuming its just as simple but expands on the field sizes, timing improvements, and flexibility in terms of non-western music as it seems to promise.
Did anyone else collect MIDI files in the pre MP3 days? I don't know what happened to my collection, but I had everything: pop, classical, movie scores, etc. I loved how they managed to recreate intricate and grand things in a limited format.
> Did anyone else collect MIDI files in the pre MP3 days?
Oh yes! And I still copy them over every time I migrate to a new music making computer. And play them back every few years for a good smile.
I even spent quite a bit of money on commercially produced floppy disks of midi files containing arrangements of popular songs of the day. It enabled an early form of remixing those songs.
This was quite a thing during its heyday and was quite interlinked with the MT-32 sound module by Roland, which also ended up spawning an entire subculture of classical music lovers transcribing countless classical (and thus public domain) pieces into MIDI and posting them on BBS systems.
Some of the modern classical midi archives on the web are descendants of those BBS sharing communities and I'm assuming that numerous midi files on current websites are actually from those days (late 80s to early 90s).
The eventual standard MIDI GM (for standardizing program change messages into specific instruments) and subsequent dialects like Roland's MIDI GS and Yamaha's MIDI XG standardizing control change messages for FX like reverb etc. all stem from those days.
The MT32 and later Sound Canvas series modules and Yamaha's competing models like the FB-01 eventually ended up becoming incorporated into many PC sound cards.
Oh, definitely. Even after MP3 compression came along, MIDI and MOD files were just so much smaller and quicker to download over a modem at my baud rate.
I collected them from FTP sites and still keep them (later on vanbasco.com made hoarding MIDIs unnecessary)
One of my guilty pleasures is to get a well done MIDI file from that era and render it using my Kronos and Logic loaded with NI, Arturia stuff. It’s impressive how you can produce something that was basically inconceivable to the original MIDI author that was using perhaps a Gravis Ultrasound.
I certainly didn't have that great of a soundtrack when playing Ultima V back then on my my C64 (AFAIK there was no MIDI support in C64 games and no MIDI add-on for the C64? Although I may be wrong on that)
Back in that era, '87 +/- 1, a friend loaned me a CZ-101 for a little while. We both had Atari STs, which had built-in MIDI ports, and many games supported MIDI out and specifically the CZ-101 (this was very pre-General-MIDI). It was amazing. Never got one for myself.
Not specifically - there are lists online and the games I remember playing a lot aren't on them, so my memory must have gone fuzzy over the last 35 years.
My favorite bit of marketing ever is the Live from the Sierra Lounge casette from 1988 which is an advertisement for the Roland MT-32 and AdLib. The first side compares it to basic computer audio and side two is just music with several game themes played on the MT-32 (and maybe AdLib for some?).
MIDI is just as amazing as it is limiting. I have a DX-7 here built up from salvaged parts that talks to all of my more modern gear like it's perfectly normal.
Try hooking up a computer peripheral from that era, say a Centronics printer or an MFM drive to a mobile phone and let me know how it goes.
when Sound Blaster came out with SoundFonts and the AWE32 they really made .MID files shine. Old MID files that sounded pretty bad on a previous Sound Blaster or AdLib suddenly sounded amazing.
And you think, wouldn't it be cool if the .MID contained the SoundFont? And... you get .MOD files, which were unfortunately seen as this weird demo scene format but were quietly doing things the music industry had not gotten around to yet. It was MID that would sound identical on any machine you played it on (assuming said machine had PCM playback)
Tracker music definitely had its day in computer games, and around the same time a lot of sample-based music was happening on video game consoles. There was just a pretty short amount of time for software or hardware sampling to shine before games started being shipped on CDs with more than enough room for full orchestral recordings and whatnot. I still notice tracker music in indie games every once in a while, and one of the bigger sound middlewares in games today had its origins there:
The shortcoming, I think, was file size for the samples. I mean 2MB was about average RAM for a new home PC in 1996 and sampled sounds at 16bits x 44 kHz would eat that up pretty fast.
That means putting them in ROM and that means compliant hardware or CDROM latency.
How is that possible? The builtin QuickTime Player on a Mac can play .mid files already and if they have GarageBand, a free (as in beer) download from Apple they can choose an instrument to play that .mid file. I love .mid files.
Whenever I need to explain MIDI to someone who has no idea what it is I ask them if they know what a player piano is. If they say yes, I say: It's that, but for computers, they seem to understand.
My mom was a pianist and purchased a Yamaha diskclavier in the late 90s. One summer I was able to download the Final Fantasy 7 soundtrack to a floppy disk in MIDI format. Was then able to insert the disk into the diskclavier unit and the piano proceeded to play FF7 songs with the keys and everything. My parents thought I was some genius at the time :)
I have one here and it is an amazing machine. Mine is about a decade old, bought at a very steep discount compared to the new ones, but it is in mint condition, whoever owned it first hardly ever used it. My first experiment was to hack a disklavier mechanism into a rickety old grand piano, and while that worked it did not give me the recording capability and a good action so after two years of tinkering I bit the bullet and bought the real thing. Amazing to mess around with that, I wished there was more time in a day. I also use it to test my software on and it's always fun to see people that can play well realize the kind of tricks that you can pull with it.
It's also a bit eerie, to see long dead pianists play from rolls converted to MIDI files for instance, it really has a 'ghost in the machine' kind of feeling.
Anyone who might need a MIDI reference to get serious about its versatility? If so, you'll want to find a copy of 1996 book "Midi Files" by Rob Young. ISBN 978-0132624039. (2021 2nd ed. ISBN 9780130608635.) Starts with the easy stuff, well-written and organized, detailed, and thoroughly indexed.
Complaining shouldn't be allowed by anyone who hasn't studied it.
You can't know what it can't do until you know what it can do. Many critics just don't know. And can't be bothered about that computer junk. Meanwhile, many top producers in Hollywood produced top-grade filmscores with it.
32Kbits per second is about 3000 bytes or 1000 of MIDI's biggest commands per second. Even 100 notes per second leaves a lot of room for CCs, NRPs and other controllers. Oh, and a rest is the distance between a note-off and a note-on ... if you actually have to convert to notation.
> "The standard is 40 years old and good for another 40, it’s so perfectly suited to the task."
That's true, if you consider the task at hand to be allowing any piano-like keyboard controller to connect to any synthesizer and just work.
It starts to break down if you consider it as a protocol for general-purpose musical expression. No explicit support for any tuning other than 12-tone equal temperament. No support for unisons on a single channel. Some support for per-note expression, but there's not really a sane way to support volume swells that works in a predictable way across devices.
I think it should be possible to improve upon MIDI and make something that's a lot more flexible without adding too much complexity.
MPE is a pretty good temporary workaround, but it's not the kind of thing you'd do if you were designing for expressive instruments from the start.
I’m quite interested in expanding what can be done with digital and programmable music/accompaniment, but I’ve never knowingly sent MIDI data over a physical wire, only software interfaces. So, grain of salt…
I think MIDI is very well suited to build on top of, without needing to change the spec. Most if not all of what you discuss can be built in software (and hardware! but it might need to be purpose built for some tasks, which is admittedly a weakness of the aging spec) with MIDI’s existing features.
Importantly, I think that can be done without introducing ambiguities that would require end users to pierce the abstraction layer. (I say this as someone who works on projects rooted in a relatively younger but also old-by-today’s-standards spec, with very good abstractions built atop, but breaks down for certain use cases in ways that came up just today in my weekly check in.) Granted being such a small, low level target means it’s easy to get those abstractions wrong. But as someone might say of a house, it’s got good bones. A motivated person with the right tools and skills can do incredible things.
I’m not sure that’s a compelling argument that MIDI objectively should remain unchanged for the better part of a century. But it’s compelling enough I’d scrutinize any proposal to revise for its thorough in-spec alternatives.
I think the Open Sound Control (OSC) protocol addresses some of the issues with MIDI 1.0, like higher resolution values, tunings beyond 12-tone equal temperament, etc., without the complexity of MIDI 2.0.
OSC is just a way of packaging messages with an optional timestamp, despite its name, nothing in OSC is specialized for audio applications. There is no pre-defined convention for "Note-On" messages, "Note-Off", "Sustain Pedal" etc... If someone had taken the time to define these messages maybe it could have been a replacement candidate, but without this it offers nothing more than json.
Also OSC is typically transported on UDP messages (because it is easy to do), but that's a terrible transport since it is unreliable, and messages larger that some OS and network dependent size are just discarded, so you can only use it reliably for message bundles smaller than a few hundred bytes.
> I think MIDI is very well suited to build on top of, without needing to change the spec.
I disagree. I think MIDI uses a basic abstraction that's awkward for anything that's not piano-like, and attempting to fix it by laying things on top just muddles things. MPE works around MIDI's limitations, but it's not a very clean interface. Users have to be aware of whether they're using MPE or not. If they are, channels don't work the same way as when they aren't.
(And interestingly MIDI gets things wrong in about the same way that standard music notation fails.)
I think MIDI's main mistake is that it assumes that a key, a note, a pitch, and a voice are all unique and be used to uniquely identify each other. So, for instance a keyboard can send NOTE-ON 72 127 when someone hits the C4 key at full velocity, and then when they release it the keyboard can send NOTE-OFF 72. There's this assumption that there's only one C4 being played at once, so the keyboard can just say, "stop playing the C4 note" to get it to stop. This breaks down if you send two NOTE-ONs for the same note in a row (which I think is technically allowed), but sending a NOTE-OFF when there are multiple notes playing is undefined behavior.
The way most synths actually work internally is that you have one or more voice engines that can be tuned to any arbitrary note.
I think a more sensible approach is to just have the controller allocate voices explicitly, and then tune them however it wants. Voices can be referenced by a unique ID that's independent of pitch.
For instance, the controller might send messages like, "hey, I want to allocate a new voice which I will call V1; please set aside one voice engine and tune it to 261.63 hertz". The controller might do this before the user even hits a key. Then when the user hits a key it might send a command "please apply a percussive envelope to voice V1 using such and such parameters." When the user releases the key it might send a command "please apply an aggressive damping filter to voice V1". And so on.
The controller might want to allocate more voices than the synthesizer actually has, but that's fine -- modern synths generally implement some notion of voice stealing anyways.
My first home computer had a sound blaster 500 sound card (remember when computers needed sound cards?) which had built-in MIDI support. The thing that absolutely stood out about MIDI is the small file sizes and crystal clear sound quality. All it effectively needed to encode was the meta data about the instrument - it’s analogous to encoding sheet music into a file format! What a blast from the last.
CEC (the HDMI Consumer Electronics Control interface) is satisfying, in a similar way. An ethernet for, more-or-less, video-based consumer electronics. Exploring it is a joy, if only because of its constraints and simplicity when compared with TCP/IP.
I struggle to find use case? It seems to inherit MIDI flaws and...not be compatible with it aside from maybe making MIDI device that sees it do something funny ?
Like, the MIDI format is pretty elegant and easy to decide but why inherit limitations of 14 bit numbers and continue using "sysex" as kludge to drive everything ?
Keep the format of <command><channel> (really, <channel><command> is probably better for decoding but whatever) but then instead of the silliness of 7/14 bit encode rest of the parameters properly
No it doesn't have to, version 1 was very inefficient, MIDI 2 uses the same cable and is backward compatible, encoding is improved, cool thing it's bidirectional.
edit: from midi wesite -->
Can MIDI 2.0 provide more resolution?
Yes, MIDI 1.0 messages are usually 7 bit (14 bit is possible by not widely implemented because there are only 128 CC messages). In MIDI 2.0 velocity is 16 bit. The 128 Control Change messages, 16,384 Registered Controllers, 16,384 Assignable Controllers, Poly and Channel Pressure, and Pitch Bend are all 32 bit resolution.
MIDI's issues in a notation context are twofold: non-standardization of controls for e.g. choosing articulations for string instruments, and an inability to communicate future information if known to the MIDI producer - say, for instance, knowledge that this Note On event is the beginning of a phrase that will last for 2 measures, as known to notation software.
There's a real way in which MIDI solved for communicating trigger events over the wire, but was not extensible enough to allow for further backwards-compatible standardization that would let it communicate music over the wire. By contrast, the web evolved from communicating hypertext to sending entire application environments and executable code over the same protocols. The web was born later, to be sure, but in an age where an Arduino can execute JavaScript, I wish we were looking to much more extensible modes of communication as inspiration for what can be done with interoperable musical devices.