I have a Casio 101 keyboard that I bought in 1987 and a $15 MIDI-to-USB cable. It's hard to describe how satisfying it is to see it continue to work as an input device for a computer manufactured in 2022.
The fact that MIDI 2.0 was only released in 2020 is mind boggling. It was just really well designed and implemented from the beginning.
I remember the first time I saw MIDI in action: I was in a mall in the mid-to-late 1980s and ComputerLand had a full sized keyboard hooked up to an Apple IIgs, which was playing The Entertainer while the notes scrolled across the screen on a color display. The real piano sound that came out was piped through some great speakers and I thought it was the most amazing technology I had ever seen. Think about that for a second: That tech remained almost untouched for 35 years. Incredible.
This video has a short bit in the middle about one of the first MIDI keyboards which still works with modern equipment (starting at 7:55): The History of the Prophet Synthesizer https://youtu.be/Ruh0B5QKBMs?t=476
Related (non-MIDI) note: I recently found this video about making electronic dance music on an Amiga in the early 1990s and learned quite a lot about how music-techies back then we're geeking out. Super fun - I'm not a musician, so I honestly had no real idea what was possible back then.
MIDI has proved amazingly resilient, whether over 5-pin DIN, the increasingly common TRS 1/4” jacks (common on Eurorack or guitar pedals, where space is a premium) or the utterly ubiquitous MIDI over USB. (And ethernet, can’t forget that). Everything digitally controlled speaks MIDI - and not just music, the stage lighting world is all MIDI too. I think that there is a real case that it’s the second most successful wired physical-layer protocol behind Ethernet.
I love that a protocol from 1983 is still in very active use. Either it was very well thought out, or the userbase has very limited needs. (actually a little of both.)
It is on one hand but it's also a PITA that holds back innovation and troubles its users with work-arounds.
It's time for a proper new standard using modern capabilities both for audio and control signal transport but it's a very heterogeneous market with tons of legacy, therefore almost impossible to achieve.
You know how modern 3D printers and CNC machines use "G-code" instructions to specify their movement? I learned this tidbit literally yesterday:
The first implementation of a numerical control programming language was developed at the MIT Servomechanisms Laboratory in the late 1950s... The main standardized version used in the United States was settled by the Electronic Industries Alliance in the early 1960s. A final revision was approved in February 1980 as RS-274-D.
So yeah. Remember what Gibson said about the future...
1/4" and 1/8" (3.5mm) analogue audio jacks have had a very, very long life, from as far back as the 1890s. A year or two ago when I found my mother using with her iPhone an ancient single-ear mono headphone that probably came with a cassette player in the 80s, which struck me as quite funny. Still works fine.
This is really good news, finally I can stop telling users of pianojacq.com that they have to use Chrome or jump through all kinds of hoops to make this work on FF. Will test this out soon and change the code if necessary to make it work.
Edit: see other comment in this thread, no dice for now :( I'll have to do some more digging as to why it doesn't work.
Fingerprinting of WebMIDI devices is already happening in the wild. It was discovered because Firefox prompted for WebMIDI access on some random e-commerce websites, whereas Chrome silently allowed websites to access MIDI devices.
There are many legitimate reasons for webapps to do so, like game controller for games (or programming usb connected robots), sensors, or like in this case, connect a synthesizer to it, but little reason to allow random websites to have that.
I just would wish, there was a more clear distinction between them.
I think the connection from the browser vendors to the ad companies are not helping with that.
Whitelists/allowlists are tricky, because they create a bias towards existing, larger players. If you're creating some new gadget, you now have to convince the browser makers to allow it through. And the browser makers need to come up with some way to have a level of confidence that requesters are not just trojan horse manufacturers. Or so lax on security that a rogue website can use your USB connection to reprogram the device's firmware to emulate an ethernet device that will MitM your network.
You can let the user accept new entries, but then you're back having to give random nontechnical people enough context and information to make the correct choice when a random website causes the permission dialog to appear. Empirically, that doesn't go too well.
It's such a cool capability. Adds so much creative possibility. Huzzah.
I hope some day we get to a WebMIDI 2.0, to expose some of the many many new super-rad features in MIDI 2.0.
This want iconifies a lot for me, as sensible & highly desireable straighforwardhish follow-up I have little expectation we'll see anytime soon. I generally love the web platform, find it does a solid job, has decent API shape & decisions. Stuff gets made, & pretty well. But there's definitely a dearth of spec workers & browser maintainers out there to pitch in after the first drops, especially after some 1.0 implementations make it out the door. Just like in normal software development, there's a budget for new development, but maintenance & improvement can be severely lacking. Attention for what we have, tlc, is sparser than the places where new things happen.
WebMIDI is alas one of these great worthy & amazing specs that at some point we need to re-up, come around to again, and I want so much to imagine that happening. I feel like WebShare (and Target) was another great example- lots of really good improvements asked for in issues, growing potential, but the interest from the top has moved on.
I believe it was removed because of the high risk of fingerprinting and inability to safeguard it from sending malicious data to devices (some devices do firmware updates over MIDI)
Everything that updates firmware over MIDI should have an explicit "update" mode on the hardware itself. No MIDI instruments I've ever used are writable by-default.
Also, fingerprinting is easy to avoid here. Firefox leaves MIDI off entirely until you opt-in to avoid random websites picking it up. Safari could do the same, presumably.
Could it just be hidden behind a prompt to enable it on a given site?
I feel like they’re just using fingerprinting as an excuse to not implement functionality that people want. Of course, I don’t really understand the problem space, so it’s likely I’m missing something.
Can anyone explain to me, what's cool on web midi? I me for me it's totally useless.
I have a lot of sequencer, synth and midi help plugins in the DAW ... what does a JS interface to the web offers other than the next 100th "I just wrote a little useless javascript music script"-show HN posts?
For me it doesn't solve any problem or satisfy any need. It's just another other thing almost nobody uses in the browser.
One use case is education, where a web app is often easiest to build and deploy.
There are lots of rooms equipped with computer, notation software and keyboard in music institutions, where webmidi seems like a great way to develop some quickie music theory/education apps.
The web is not anywhere near parity for music and audio production yet, but its proponents see webmidi as one necessary step to that direction.
(I would personally not use current webaudio/webmidi software, but have successfully deployed a lot of it for education!)
I would argue it also lowers the barrier to entry for experimenting with new techniques for generating/processing audio. For example, you could pretty quickly create a page that has touch controls for adjusting parameters, uses a neural network for generating MIDI data, and then outputs that MIDI to a VST running on your computer.
Already on it... I will likely have to tweak the startup code a bit, look for an update tomorrow.
Edit: Ok, just tried it after upgrading FF, it doesn't work at all when used locally ("secure context required", as if there is anything more secure than using a local file...), and when using it on the server it does get past the initialization but the device list isn't populated, so whatever they are doing it isn't 100% compatible with the way Chrome does it.
The 'expected behavior' would be that the permissions dialog pops up but it doesn't so for now we'll have to wait until that is fixed. Pity, but it's very close now.
Novation has a pretty impressive web midi implementation used for managing the configuration on some of their controllers and synths. nice to see that becoming a thing outside chrome
Now if only they made one that wasn't web based. If I want to configure my LaunchKey on desktop, I'm still stuck with a huge electron app instead of a normal config application.
This is the same for the Nektar Pacer, the physical interface is a bit of work to get through, but someone made an amazing web midi configuration tool allowing complex configurations to be made or transferred between units.
Readit News
I remember the first time I saw MIDI in action: I was in a mall in the mid-to-late 1980s and ComputerLand had a full sized keyboard hooked up to an Apple IIgs, which was playing The Entertainer while the notes scrolled across the screen on a color display. The real piano sound that came out was piped through some great speakers and I thought it was the most amazing technology I had ever seen. Think about that for a second: That tech remained almost untouched for 35 years. Incredible.
This video has a short bit in the middle about one of the first MIDI keyboards which still works with modern equipment (starting at 7:55): The History of the Prophet Synthesizer https://youtu.be/Ruh0B5QKBMs?t=476
And for fun: 1986: MIDI and the MUSICAL MICROS | BBC Archive: https://youtu.be/aADkqmvy44o
Related (non-MIDI) note: I recently found this video about making electronic dance music on an Amiga in the early 1990s and learned quite a lot about how music-techies back then we're geeking out. Super fun - I'm not a musician, so I honestly had no real idea what was possible back then.
https://youtu.be/6OaBkvwx7Hw
No-one uses MIDI 2.0 yet, we don’t need it! MPE (https://www.midi.org/midi-articles/midi-polyphonic-expressio...) is only just being adopted (with poly aftertouch instruments and keybeds like the ones in the ASM Hydrasynth).
MIDI has proved amazingly resilient, whether over 5-pin DIN, the increasingly common TRS 1/4” jacks (common on Eurorack or guitar pedals, where space is a premium) or the utterly ubiquitous MIDI over USB. (And ethernet, can’t forget that). Everything digitally controlled speaks MIDI - and not just music, the stage lighting world is all MIDI too. I think that there is a real case that it’s the second most successful wired physical-layer protocol behind Ethernet.
And MIDI also has SYSEX to handle arbitrary data.
It's time for a proper new standard using modern capabilities both for audio and control signal transport but it's a very heterogeneous market with tons of legacy, therefore almost impossible to achieve.
The first implementation of a numerical control programming language was developed at the MIT Servomechanisms Laboratory in the late 1950s... The main standardized version used in the United States was settled by the Electronic Industries Alliance in the early 1960s. A final revision was approved in February 1980 as RS-274-D.
So yeah. Remember what Gibson said about the future...
https://en.m.wikipedia.org/wiki/G-code
Check out the Example section for the 1964 RUNOFF document editor. You might see some familiar things
https://en.m.wikipedia.org/wiki/TYPSET_and_RUNOFF
Also communication protocols have pretty long lifespans. Take https://www.kermitproject.org/ for example or the wire standard for Ethernet
Dead Comment
Edit: see other comment in this thread, no dice for now :( I'll have to do some more digging as to why it doesn't work.
https://twitter.com/denschub/status/1582730985778556931
I just would wish, there was a more clear distinction between them.
I think the connection from the browser vendors to the ad companies are not helping with that.
You can let the user accept new entries, but then you're back having to give random nontechnical people enough context and information to make the correct choice when a random website causes the permission dialog to appear. Empirically, that doesn't go too well.
I hope some day we get to a WebMIDI 2.0, to expose some of the many many new super-rad features in MIDI 2.0.
This want iconifies a lot for me, as sensible & highly desireable straighforwardhish follow-up I have little expectation we'll see anytime soon. I generally love the web platform, find it does a solid job, has decent API shape & decisions. Stuff gets made, & pretty well. But there's definitely a dearth of spec workers & browser maintainers out there to pitch in after the first drops, especially after some 1.0 implementations make it out the door. Just like in normal software development, there's a budget for new development, but maintenance & improvement can be severely lacking. Attention for what we have, tlc, is sparser than the places where new things happen.
WebMIDI is alas one of these great worthy & amazing specs that at some point we need to re-up, come around to again, and I want so much to imagine that happening. I feel like WebShare (and Target) was another great example- lots of really good improvements asked for in issues, growing potential, but the interest from the top has moved on.
Apple removing it is weird considering the platform prevalence with musicians...
So far, it's working. Chromebooks have not taken over the world.
Also, fingerprinting is easy to avoid here. Firefox leaves MIDI off entirely until you opt-in to avoid random websites picking it up. Safari could do the same, presumably.
I feel like they’re just using fingerprinting as an excuse to not implement functionality that people want. Of course, I don’t really understand the problem space, so it’s likely I’m missing something.
...Well, I guess I was about to answer my own question there. Never change, Apple. Never change.
There are lots of rooms equipped with computer, notation software and keyboard in music institutions, where webmidi seems like a great way to develop some quickie music theory/education apps.
The web is not anywhere near parity for music and audio production yet, but its proponents see webmidi as one necessary step to that direction.
(I would personally not use current webaudio/webmidi software, but have successfully deployed a lot of it for education!)
Already on it... I will likely have to tweak the startup code a bit, look for an update tomorrow.
Edit: Ok, just tried it after upgrading FF, it doesn't work at all when used locally ("secure context required", as if there is anything more secure than using a local file...), and when using it on the server it does get past the initialization but the device list isn't populated, so whatever they are doing it isn't 100% compatible with the way Chrome does it.
I'll have to do some more digging, sorry!
Edit2: We're not quite there yet it seems: https://bugzilla.mozilla.org/show_bug.cgi?id=1805582
The 'expected behavior' would be that the permissions dialog pops up but it doesn't so for now we'll have to wait until that is fixed. Pity, but it's very close now.
By the way, where do you get your MIDI files from ?