In theory, MIDI is an electrical and protocol standard that allows any such equipped instrument or computer to talk to any other. But as the wonderfully named [Knob Monster] will tell you, when the computer is new, and the instrument is old, it ain’t that simple.
They specialise in using the Web MIDI interface to allow browser control of an instrument. This might typically be done with a USB to MIDI interface, but in this lies a problem. The 8-bit microprocessor on a 1983 synth has problems keeping up with the rapid-fire data that spews relentlessly from the supercomputer-grade machine controlling it, and bad things happen as a result.
Expensive MIDI interfaces have a buffer built in, but a better solution lies in the Web MIDI code itself. They detail how to use the Web MIDI API’s built-in packet scheduler to slow things down a little and let your Yamaha DX7 chill a bit.
Meanwhile, if you need a USB to MIDI interface, we’ve covered one in the past.
jep. midi sysex had no standard. do what you want. I did not know about knob monster. I will check that out as I am de developing a midi interface for the Pearl DRX-1 and the computer side of the sysex chain was holding things up.
Well that was the entire point of it, wasn’t it.
Midi and midi sysex are not the same unfortunately
I didn’t know about knob monster either. It’s seems to be a nice tool that could be self-hosted but sadly they keep it as a SaaS solution with subscription-based licencing so you don’t own you beloved data voices and it’s a platform/product ready to be enshittified because of that so I’d stay the hell away of that tool if I were you.
I’d love to buy this as software, but I don’t have any interest in renting access to it. Too bad.
Same concern, we don’t rent it.
One payment, lifetime license, export .syx whenever. No monthly fee. Browser app, not a boxed installer, but you’re not paying for access to your own files.
If “buy once, run offline forever” is the bar, MIDI Quest still wins for full editor depth. We’re aiming at “backup + search + flash in Chrome without MIDI-OX.”
Agree. Subscriptions are stupid and predatory.
It is named after this girl I used to know.
Apparently sucks.
Too much chaos.
Fair pushback on rent-seeking tools, we agree.
knob.monster is not subscription. Personal is $39 one-time, Studio is $399 one-time. Paid tiers include unlimited .syx download/export; your banks are not hostage on our servers.
Cloud vault is for search/backup convenience, not DRM. If we ever changed that we’d deserve the hate. Free tier exists to try a real dump before paying.
Self-hosted would be cool for hackers; we’re web-first for people who don’t want another daemon. Tradeoff, not lock-in.
Do you have agreements in place for financial escrow of that $399 for financial reserves? How long can you expect to be around if people stop buying? Do you escrow the code so people can install it on their own stack if you go away? Etc, etc. I don’t want a fly by night tool integrated into my entire workflow that may go away in 18 months. I want something I can install on an air gapped pc that will still work in 15 years exactly like it does today. People still make music on Amigas, TRS-80s, and iMac SE-30s because of this attitude. Until you can guarantee long term viability, I’ll be sticking with hardware solutions.
Fair pushback on rent-seeking tools, we agree.
knob.monster is not subscription. Personal is $39 one-time, Studio is $399 one-time. Paid tiers include unlimited .syx download/export; your banks are not hostage on our servers.
Cloud vault is for search/backup convenience, not DRM. If we ever changed that we’d deserve the hate. Free tier exists to try a real dump before paying.
Self-hosted would be cool for hackers; we’re web-first for people who don’t want another daemon. Tradeoff, not lock-in.
“There is a regression in the new version, let me reinstall the old version” is a mandatory requirement for mission critical software.
Had to travel 400km yesterday after a Windows machine had shat itself after an automatic update. Same story.
Whenever I’m forced, at gunpoint, to install a Windows Server, I insist on a virtualized environment with snapshots at hourly intervals, so I can will back any regression with remote access to the hypervisor.
Good luck with the DRX-1 interface. Computer-side SysEx pacing was our pain too. We ended up sending complete F0…F7 messages on a schedule with midiOutput.send(data, performance.now() + offset) and ~60ms between messages instead of arbitrary byte chunks. Happy to compare notes if you hit a specific failure mode.
Can this not be as simple as reducing baud rate on serial devices?
Even Back in the 80s, we had tools in sequencers to reduce the density of CC messages. Midi is only 31.25k baud… It’s easy to choke it with continuous controller data.
Any proper tool should know to rate limit itself.
Yup, came here to say this. MIDI is at a fixed standardized baud rate that even old 80s synths with 8 bit processors could easily handle. I’ve used well designed modern MIDI controllers on vintage synths, I’ve used vintage midi controllers on modern synths, and I’ve used modern cheap USB to MIDI devices on synths. Hell I’ve even used SPG on MSDOS 6.22 to control synths, new and old, over MIDI. The issue isn’t 8 bit processors not keeping up with modern MIDI, it’s lazy modern day programmers not buffering their MIDI properly so that their 31.25k UART line isn’t choked
yep – “The issue isn’t 8 bit processors not keeping up with modern MIDI, it’s lazy modern day programmers not buffering their MIDI properly so that their 31.25k UART line isn’t choked” is the best summary of this article in all the comments.
I’ve used cheap usb/MIDI controllers on old keyboards for decades, and written my own code to interface. Never had a problem.
MIDI has proven to be one of those interfaces that has just survived well, which shows it was thought out well in the first place given it’s now been 40+ years…
I was gonna point that out, too, MIDI 1.0 standard were only 31.25K baud, which was kind of sort of okay for simple “multi-timbral” messages (ie, more than one note per, a in “chords” or “multiple instrument played simultaneously”), but once things like mass pitch bends are added (or sys commands) 31K becomes not a lot, really.
IMHO, 31K was actually quite good for the times when average dialout modem was maybe 1K at best (was it 1983 or 1984? I’d speculate around 1984 when it was widely accepted, but could be as early as 1981).
That MIDI 1.0 survived largely unchallenged until 2020 (MIDI 2.0) tells me it withstood the test of time rather well – together with simpler/humbler things like RCA connectors (or 3.5mm headphone jack) or RJ45 or CAN bus. Speed was the largest complain I’ve heard from everyone, but I personally haven’t seen any other comparable older/simpler tech standards (in the music industry at least) that would hold that well. Pros have different opinion, and I respect that, but I am just a budget-strangled average Sam, not a 1980s recording studio, and for me it worked spectacularly well even with (what’s now considered old school slow-mo) 31K speeds.
Agreed. CC floods and long SysEx bulk dumps to battery-backed RAM are different problems. We only throttle outbound SysEx when flashing banks back to hardware, not note traffic.
Sometimes there are unintended consequenses, when something is initially developed, stuff works. But thinking about faster processors didn’t cross their mind. At example of that same scenario happened with Windows 95… Install it on an old 200 MHz machine and it will run fine. But try it in a modern fast computer in a virtual machine running at 2 GHz, it fails and locks up. (There was a 3rd party patch made that fixes it.) Perhaps the same thing needs to be done here… My brother has old midi equipment that’s tempermental now. I don’t know the model, it’s a 16 track mixer.
Hi! Right, there’s a patch for this by now.
http://www.lonecrusader.x10host.com/fix95cpu.html
Windows 95 was built upon Windows 3.x architecture,
which itself ran on 8088/286/386 era PCs with a clock frequency of a few dozen MHz.
So sue to its historic background, it understandibly ran most stable on a 386/486 era ATs with plain ISA bus or ISA/VLB bus.
I saw Windows 95 RTM running most stable on such classic/traditional PCs, at least.
Interestingly, unmodified Windows 3.x in Real-/Standard-Mode runs fine on super fast GHz PCs.
I suspect the main problem rather lies within the use of VXDs which are both very flexible and unstable by design (formerly *.386 files).
The 386 Enhanced Mode that uses them has become the base of Windows 95.
In a nutshell, Windows 95 is a pile of poorly written/debugged VXDs, basically.
By comparison, Windows 98SE is much more forgiving.
It also uses WDM drivers, whenever possible.
The Pentium 4 also had caused compatibility issues,
because some instructions (such as LOOP) were processed in a very low number of cycles.
The CPU was being too efficient for existing code, basically.
Later CPUs were slowed down on purpose as a workaround.
“Intel Pentium 4 (tested on Irwindale Xeon) appears to execute the LOOP instruction in two cycles, noticeably faster than older and newer Intel CPUs.”
https://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/
Good analogy. Wrong pacing for the target era is the same class of bug, different stack.
I’m sure you and I got all excited with the promises of MIDI. My mum being a piano player got an electronic keyboard at some point. In a parallel universe I got a 486 with Soundblaster and joystick/MIDI port. Problem being the keyboard MIDI was round and joystick was DE-? The highlight was getting pinouts for the respective ports (http://pinout.something), building a cable and using the keyboard as a slave to play music from the PC and later using the PC to transcribe keyboard playing to a manuscript with some obscure software.
Interestingly, the Sound Blaster cards had two types of MIDI interfaces. SB-MIDI and MPU-401.
SB-MIDI was used on the 8-Bit cards and handled by the DSP, while an MPU-401 interface was added to the SB16.
But only in dumb mode (UART mode), which software from the 80s didn’t like.
Old software assumed the normal mode (intelligent mode), which had metronome etc.
The MPU-401 on SB16 and PAS16 basically was a serial port without much intelligence.
Some higher end soundcards fooled old software into thinking that intelligent mode is available by answering with an “ACK” (acknowledge) message.
Later SB models, such as certain AWE models do emulate that MPU-401 in software (but again, UART mode only).
Which isn’t available in Protected-Mode software, also.
Nowadays, SoftMPU emulates an intelligent Roland MPU-401 in software (on DOS).
The DE-15 connector was used as the standard PC gameport connector since early 80s.
IBM itself called the gamecard the “Game Control Adapter”.
The Sound Blasters then simply used two unused pins for RX/TX to provide MIDI i/o.
That way, no extra MIDI connector was needed on the card.
It perhaps made sense in a time when MIDI was more thought of an gimmick among home users.
A gameport to DIN adapter cable was once sold optionally, I think.
My brain is also filled with useless technical trivia from that era…
Netmare dgroup ram and losing a file service process because I added RAM.
Does regurgitating it on forums help you garbage collect?
For me, It would make it even harder to reclaim that wetware space.
Hm, good question! I guess I simply find such technical details fascinating and worth sharing? 🤷♂️
Such oldschool knowledge perhaps isn’t entirely useless if current VM software still has optional SB16 emulation, for example?
I mean, there’s some more industry standard hardware that’s still with us.
Such as SVGA/VBE or IDE ATAPI/SATA or various network adapters..
Virtualizing old servers might involve fiddling with DOS packet drivers or PCNet adapters, who knows.
Another one filled with old technical trivia enjoying passive reading. Keep up the vibe!
Another problem with modern MIDI – different types of dongles with 1/8 inch (3mm) connectors!! Yay!!! You wouldn’t know it but you can’t use the same dongle on an Elektron that you can on my Arturia. Don’t know why but….. yup. It’s a thing apparently. If it ain’t broke… fix it, so people have to buy your proprietary copy.
My Moog dfam support only 3.5mm trx midi… Though many modular does too
Modular TRS MIDI is its own adapter drawer. Same pain.
TBH, any decent MIDI device should be able to fully handle constant data at 31.25kbps.
I could see a few failure modes, though:
If the USB to MIDI device sucks, it could be dropping bytes of a full MIDI packet if the buffer is full.
With SysEx messages, all bets are off. You need to send those messages as the manufacturer intended. Theoretically, this could include throttling messages, especially if it’s writing non-volatile memory.
BTW, when you say “modern MIDI,” I think MIDI 2.0, which is an entirely different beast.
The fact that was midi was a standard that a few companies actually agreed on in the 1st place and then mostly followed for many years is/was almost unbelievable today. The MPE midi mess that exists today is a perfect example of how things normally go.
That being said any modern midi gear that doesn’t rate limit the data it sends is just junk / badly made!!!
MPE fragmentation is the modern counterexample. Any bulk SysEx tool that does not rate limit is asking for trouble on vintage RAM writes.
Even back in the early 90’s, my Win98/MPU-401 and Emu-Proteus required a Cakewalk configured byte delay for successful sysex patch bank transmission. The 10 bits of each midi byte flowed at MIDI 31.25 Kbps. Cakewalk was configured to delay each sysex byte by about 100 microseconds to slow the overall sysex byte rate.
For a recent effort to get my old equipment to work with a modern laptop/USB MIDI interface, I hacked together a basic CLI sysex tool using the linux ALSA RawMidi interface. https://github.com/don-bski/WrkFile2Mid/tree/main/syxmidi. There are also other tools; MIDI-OX, Bome SendSX.
This is the real-world precedent. Cakewalk byte delays and your ALSA syxmidi approach are the same idea we hit from the browser: slow the sender, not blame the DX7. ~60ms between complete SysEx messages with scheduled Web MIDI sends fixed our flash path. Nice repo, will poke at syxmidi.
Using a real dx7 in 2026 when we have dexed lol
I reverse engineered the midi sysex protocol for EAW MX8750 if anyone’s interested let me know please