How will MIDI 2.0 change music? (2020)
qz.com
qz.com
However, the nice thing about MIDI is that it allows me to hook up my 2020/2021 synthesizer (a Behringer 2600) to a 1987 sequencer (a Yamaha QX5), a 2015 synth (a Roland JD-Xi), or pretty much any piece of pro synth gear made since 1983.
Now, with MIDI-over-USB or what not, we lose something which makes MIDI very nice: We can connect a hardware keyboard to a dedicates sound module without having to have a computer involved. While there are USB host synths which one can connect a MIDI-only-over-USB keyboard to directly, they are few and far between (my JD-Xi has USB, as does my 2600 and Arturia Keylab controller, but all three can only be hooked up to a computer with USB)
Until MIDI 2.0 has a way to allow synths to be connected to each other without involving computers, and there is a standard way to do that (I think USB-C would probably be best for this), DIN MIDI 1.0 will be a part of pro and bedroom recording studios.
I shudder to think of a future where musical instruments require you to download an app to use them; where not only are your stove and washing machine phoning home, but your piano as well. No thanks.
This isn't a proprietary lock-in thing, it's just an unfortunate limitation of USB. Though I suppose a hardware manufacturer could release a product that only works with some special app if they wanted to go that route. (Some devices have settings that can only be accessed via a computer app.)
Attempting to even do the repair yourself will be a violation of the terms and conditions of your subscription and void your ability for you or anyone else to register and ergo use your Piano. If you know or suspect someone of violating these terms please turn them in for a free $100 gift card good for a fine assortment of musical instruments.
If we suspect you have violated these terms you have agreed to give us an opportunity to inspect and if needed disable your equipment. For an additional $200 we will haul off your now useless instrument.
Your comment could be applied to typewriters. Do you prefer the days when, if you wanted to write a book or article or something, you used a typewriter that was completely standalone? I kinda like having my "typewriter-style keyboard" connected to a computer... it opens up a ridiculous number of possibilities that you can't do with a standalone machine without a big display and a fast processor and a big hard drive. And maybe internet.... you can't exactly have Hacker News with a standalone typewriter, but you can with a keyboard that connects to a computer.
Same with a "piano-style keyboard."
Those are getting fewer and farther between, the new trend is that you have to accept a 40-page license agreement to rent a bike, you get a Fancy pet feeder that doesn't feed your cat when their servers are offline, your Samsung TV adds ads that you cannot turn off, etc.
You own and control nothing despite paying thousands of dollars for it.
I think "Vote with your wallet" is just an excuse to sit around and do nothing. It did not stop companies spying on you, selling your data, electronics becoming unrepairable, schematics disappearing, etc. Vote with your actual vote, we are meant to be a democracy first, capitalism second.
And it's not practical for your average consumer (or musician) to try to block it, or even detect it. Also, there are less and less options to buy "dumb" devices and appliances that won't spend their operating lives trying to exfiltrate data about you back to their manufacturers and their corporate partners.
https://retrokits.com/shop/rk006/
It's a midi usb host and multi-port thru-box that even boosts succulent growth while you make DAW-less jam.
It's particularly good for bridging USB and DIN midi.
The MIDI 1.0 benefit of connecting keyboard-to-keyboard really didn't last long in practice. Of course you can always do it in theory, but most practical applications at all levels need those extra features.
Go on...
this protest that we must conserve an over 30 year old standard& never ever update it is a breed of conservativism that makes me shudder. basic USB is available on a vast vast range of micros, including a huge range of under $1 ones. if you do want to use old gear, great, the are options.
Perhaps USB-C can do it as you suggest?
> - Violins come last, and it doesn't really matter because they're lazy and they'll take a few hundred milliseconds to really kick in anyway.
I think the assumption that violins don't need strong staccato/marcato attacks is wrong. I've needed it in the past, and was unable to get it from soundfonts which only have slow-attack samples. This issue is omnipresent in off-the-shelf soundfonts, and I've also sometimes seen poor articulation in music I've heard made using commercial sound libraries (which I've never purchased or pirated so I can't judge myself).
As an example of a piece suffering from slow attacks, https://www.youtube.com/watch?v=ua5VJt6jkaU is a nice remix, but feels sloppy because the flute, strings, and violin's 32nd notes are barely audible (goes from attack to release without reaching full volume) and smeared together.
It would be great if articulation messages were standardized, and then you could just expect them to be there, and if they are absent, the soundfont can simply fall back to the closest thing available. That kind of helpful logic is not possible with custom mappings.
Bear in mind that not all sample libraries have articulations. Some of the more modern libraries and plugins include a modelling component, or are pure modelling, which allows you to use controllers to get those articulations in a much more flexible way.
SF2 is dead. It was never capable enough as a format to deal with what really needed to be dealt with. It is a quintessentially dated technology, and unless your requirements for sample libraries are very limited ("make a gong-type sound when I hit middle C"), SF2 is not for you.
What's the spiritual successor to General MIDI? Or is the concept no longer viable for (or even wanted by) mainstream electronic, or even semi-orchestral, composers?
Take a look at the libraries released by Spitfire Audio. You won't find anything remotely like a GM-style collection.
There's a buzz word of the day - "cinematic" - that has been defining new sample library releases for a while now. They are definitely not focused on "here's a sort of complete set of sounds corresponding to traditional instruments".
People generally want more unique sounds. Maybe a GM bank is a good starting point for people who will work with fairly traditional instrumentation (even they eventually switch away from the GM bank itself). But it's not much use for people wanting more distinctive timbres and textures, and for "cinematic" work (read: games, films, soundscapes), that's normally the goal. It's also where, for now, the money is.
The quality is good, but it's not in the same league as specialised libraries. There are usually only two or three velocity layers (for example, the choir can only sing a subdued "aaa" or an intense "AAA"). The orchestral instruments only come with a few articulations, and the guitars and pop brass only provide one articulation each. None of the instruments have sampled legato.
Unfortunately, I think this is probably the quality ceiling for a sample library with good General MIDI coverage. If you were to add more velocity layers, articulations and legato transitions, the number of samples would start to grow exponentially, and the cost of the library would grow to match. I'm not sure there's any way around it.
I went through a phase where I was trying to put together a really comprehensive collection of samples, but in hindsight it was a fool's errand - you'll get diminishing returns fast, unless you're willing to spend huge amounts of money. Accurately emulating a live performer is a nice option to have, but it isn't actually a requirement for making good music. Huge amounts of excellent music has been made using synthesiser presets, or using instrument samples which would be considered "cheap" or "low-quality" nowadays. As long as you're willing to adapt your compositions to the instruments you have available, rather than stubbornly writing string melodies which could only be performed by a real-life violinist, you'll do well.
I've seen SNES and DS games whose sample sets handle staccato and sharp attacks better than the average soundfont out there. The cover I posted is worse than the original DS game in this aspect. I assume the Kontakt factory library is competent enough to get this right though.
I assume sample packs can't handle wide pitch bends and precise vibrato that well either. Synthesis is probably better, but the pricing I've seen is insane (but probably justified considering the complexity of simulating acoustic instruments).
- A "sustain" articulation with fast attack on the loudest dynamic (which also happens to be molto vibrato), but a slower attack on quieter dynamics
- An "attack" dial which can emulate slower attacks, but not faster ones
- A "staccato" articulation which has an instant attack, but a duration of about 0.5 seconds
- No legato, so even if you get the attack right, fast runs and ornaments are going to sound a little strange
I've encountered similar limitations with dedicated orchestral libraries. If it's not the attack, it's the expression, or the maximum note duration, or the speed of an ornament, or the timbre of the specific instrument they recorded, or something else which always dangles perfection just out of your reach.
I suspect you'd have similar problems with even the most expensive sample libraries; it's one more reason to opt out of that game altogether. If you lower your standards for audio fidelity, your musical freedom increases. When you're composing for the Nintendo DS, nobody's going to notice if you manually tweak the attack of your string sample, or fake an ornament using pitch-bend, or crossfade between two velocity layers.
SWAM is one possible escape route, but you're correct that it costs a fortune. It also has high CPU requirements, so you might need to bounce your SWAM parts to an audio track, and you'd have limited ability to put together seven SWAM violins and call it a "violin section".
MIDI 2.0 Specifications Available for Download - https://news.ycombinator.com/item?id=22411765 - Feb 2020 (35 comments)
MIDI 2.0, first major overhaul to music interface standard from 1983 - https://news.ycombinator.com/item?id=22180731 - Jan 2020 (105 comments)
Details about MIDI 2.0 - https://news.ycombinator.com/item?id=20007638 - May 2019 (147 comments)
MIDI 2.0 Prototyping announced - https://news.ycombinator.com/item?id=18946222 - Jan 2019 (195 comments)
What does 2.0 offer me that 1.0 doesn’t? I know it has new features, but I want a good argument for those features actually being useful.
The big underlying change is that MIDI 2 is duplex, which allows for device discovery, property exchange, and profile configuration. What that buys you is an arbitrary protocol for exchanging information about what things are connected to each other on the same network of devices. It should allow for a lot of cool features, like supplanting Mackie Control and Eucon with an open (or at least trivially open) protocol. One thing I think we'll see with these is more support for microtonal or arbitrary pitch systems that MIDI currently can't realize.
Jitter compensation is built into the protocol too so it should resolve some of the timing issues with USB.
Having read through the spec and written the data structures out for it already I'm not sold that it's overly complex. The additional annoyance is that it mandates JSON parsing but that isn't a tall order these days.
Eucon is a perfect example of how to make a control protocol so powerful that nobody can ever really use it, or at least, not more than 5% of its capabilities.
Mackie and Eucon do not provide music performance data, so they would never be involved in pitch control. MTS can already be used to do microtonal stuff, but very few synthesizers are MTS aware, so the fact that you can do it already with MIDI 1.0 doesn't help a whole lot. Maybe 2.0 will encourage (a few?) more synth makers (soft/hard) to support MTS and/or the new stuff, but maybe it won't.
Since MIDI is already going the opposite direction of say AES67 and reinventing wheels is ok, a custom binary encoding would have made more sense to me. Something that can be encoded in a C89 struct without a ton of trouble or doesn't need much thought put into an allocator on bare metal devices to get the handshake working.
I believe it's not strictly JSON though, I don't have the docs in front of me but iirc strings have a max length. So that's good.
Essentially: for traditional western music, it seems to just offer better flexibility and precision, but it will make a huge difference for microtonal music. Honestly, being able to adjust parameters per-note simply makes sense.
(I am not a musician, just a programmer who has dabbled in a small amount of music software and protocols.)
MPE is already implemented with MIDI 1.0.
The only limitation of using channels for MPE is that you can't daisy-chain MPE devices... Which nobody really does anyway (most of my gear doesn't even have a THRU port).
Now with MIDI 2.0 support becoming a 'checkbox' item for customers, all the manufacturers will need to revisit their MIDI implementations in upcoming product releases (some already have). I suspect many will use this as an opportunity to increase input dimensions and expressiveness - which is a very good thing for all of us users, even if they do so in ways which may have technically been possible before.
Midi 2.0: 4,294,967,296 steps
https://www.midi.org/midi-articles/details-about-midi-2-0-mi...
Ever heard of NRPN, my friend?
There's a reason why this part of the MIDI spec is rarely used. And the reason is that the musicians don't need it.
If you can hear stepping on your pitch bend or filter, it's not because MIDI, it's because the implementation on your device is stupid.
Personally, I was disappointed they didn't even make a stab toward addressing higher layers in the stack like standardizing multi-channel mixing control beyond the ancient 'defacto' Mackie HUI format or some attempt at a framework for software plugins running on hosts to display GUI on controllers (even something very open/extensible ala HTML/CSS). That could have unleashed waves of innovation from indie and smaller developers.
MIDI 1 is one of the easiest protocols I've ever interfaced with myself. Getting started on any platform is easy, the API is not that large and it's relatively straightforward. You can on Linux write bytes directly to /dev/midi and get up and running really quickly, and the specification is not that big. See https://ccrma.stanford.edu/~craig/articles/linuxmidi/ for some examples.
What did you find hard in implementing MIDI 1? Would be nice to hear the opinion for something I haven't heard in real life (yet?).
A full state machine for MIDI is much more complex than it tends to initially appear. But yeah, it's not rocket science. It's not even as hard as grappling with std::move()
And you can add in that vendors also have weird proprietary sysex messages a lot of the time. Also I second a sibling comment here, there are a decent number of gotchas with the state machine.
Or because you are stepping across 5 octaves instead of just one.
The very few electric pianos I've played that didn't feel painfully limiting in dynamic expression were high-end instruments with a whole lot more than 127 velocity values.
Similarly, I have the obscure but magnificent Nord G2X, which mostly uses MIDI for mapping physical knobs to parameters in patches, but its mod wheels are much higher resolution.
I strongly prefer the mod wheels for params that cover a wide span, like filter cutoff frequency, because I can feel and hear the stair-stepping when using knobs.
That said, I'm definitely looking forward to having it reduce the number of hacky workarounds we currently deal with to get high resolution data in convenient forms. Honestly to anyone not deep into the weeds on this stuff it will be meaningless.
That said, I'm kind of pessimistic about MIDI 2.0's prospects. Maybe it'll be adopted by most of the manufacturers, but it's not looking like anyone is in any great hurry to start making compatible hardware.
There are also some problems that MIDI 2.0 just doesn't address (as far as I know), like the limitation of 128 notes per channel, or the difficulty of expressing a volume swell in a way that a synthesizer will play in a predictable way.
MPE is a thing as well. As the owner of a Linnstrument, I get 10 finger multiple pitch bend over a standard Midi connector to all synths who understand MPE (which are sadly not many, but hey)
Don't get me wrong, an improvement on Midi is long (like decades long) overdue, and I'm looking forward to it. It's just not the sea change that the hyperbolic article was claiming, not even close.
I don't really expect mainstream music to suddenly start making extensive use of seven-limit just intonation just because MIDI 2.0 has per-note pitch bend, but for the people who care about it at least we could see a lot more interest in expressive instruments and non-12-EDO musical performance. Even if it's only 5% of musicians who care about any of this stuff, that's still a lot of people.
Awhile ago, I built a keyboard instrument with 156 pressure-sensitive keys. It's 5 octaves, 31 notes per octave, based on a just-intonation tuning system. Basic sound demo here: https://www.youtube.com/watch?v=Ep52Vh6oAOE
The Lumatone has 280 keys. https://www.lumatone.io/
The Tonal Plexus H-Pi is basically a big array of buttons, arranged in 205-tone equal temperament across 6 octaves. That's over 1200 distinct notes. There aren't many of these in existence, but a friend of mine has one. https://hpi.zentral.zone/tonalplexus
For a 12-TET example, one could represent a 6-string guitar with 24 frets as having (24+1) * 6 distinct notes, or 150. Even that is over the limit.
It's possible to work around the the limited number of notes by using the one-note-per-channel trick (formalized as MPE); then you're limited to 16 notes of simultaneous polyphony because that's how many channels MIDI has, but you can pitch-bend to exactly the note you want. But then you're using MIDI in a very different way than it's usually intended, and it's hard to do that without making the user experience worse in various ways.
MIDI 2.0 could have expanded the number of notes so that (with per-note pitch bend), no one would ever have to use the note-per-channel trick again, but that's not the choice they made.
The only occasional problem I'll experience with midi is if I unplug before sending a note-off for a note, then that note might forever be stuck on.
If I had to implement such things on top of an improved protocol, I would likely also ditch the serial link, ignore completely USB, and jump straight to Ethernet, which is damn fast, near realtime, supported pretty much everywhere (Ethernet switches would essentially work as MIDI Thru boxes) and free of royalties. Devices in the same local network wouldn't even need the transport and above layers to work, so latencies would be extremely low, but adding more IP stack layers would allow to remote things easily.
And could optionally use ptp (precision time protocol) Ethernet interface so that the local network clocks are synced to sub-microsecond precision, and so can put timestamps on the midi messages so they can be properly sequenced.
And for increases reliability, incorporate with AVB which uses stream reservation to ensure priority packets can get sent.
Btw I think the hard part is probably not he implementation of Ethernet, but getting hardware vendors on board. Midi 2.0 needed a lot of companies to be on board for the change.
Perhaps if you make adapters and translate devices to help folks transition.
https://www.thomann.de/gb/bome_bomebox.htm
https://openmuse.org/transport/mip_oview.html
http://www.linuxsampler.org/ethernetmidi/
https://qmidinet.sourceforge.io/
etc.
Incorrect :) MIDI OUT provides power. No power = disconnect.
That's not to mention that you don't need a signal for *physical disconnect Your stereo knows when you unplug headphones.
Moreover, MIDI is a digital signal which doesn't carry any status about the media it travels through; I mean, 10 seconds of nobody playing would appear identical to 10 seconds after a pulled cable.
If you're lucky the result will be in-time-ish, but it's never going to be sample accurate.
This actually matters for some applications, including sound design. If you trigger two samples with a variable offset you can get phase cancellation and other easily audible effects.
DAWs are sample accurate now, but 5-pin DIN MIDI 1.0 really isn't.
If new devices come out they're going to need to work with the rest of my setup, or they're going to be a hard sell.
I imagine most devices that come with MIDI 2.0 will have an option to run in either 1 or 2.
Oh really? Riddle me this, then: a MIDI controller has a USB port. A synth has a USB port.
Connect the two without using an external power source for the adapter (Hint: you can't).
The data transmitted over MIDI and USB MIDI is the same, it's not the problem. It's the same protocol.
The problem is that MIDI OUT on a MIDI controller supplies power, and USB midi out on a device DOES NOT, because it's a slave device.
This a physical layer problem no matter how you slice it.
Now go and read the question I asked again.
> Physical layer is the easiest thing to get an adapter for
I'm saying it's not.
Truthfully there is nothing to be gained for me continuing this exchange because I in fact have plugged a Keith McMillen k-board into an op-z and a circuit rhythm and noticed it working perfectly, so your truisms are just that you don't know any synths that are battery powered usb hosts, a problem which is entirely unrelated to your inability to understand the difference between physical connectors and the logical models and data processing issues you described as physical in some weird need to repeat what I said while insisting I am wrong.
Have a good one.
I'm pretty bummed out about MIDI 2.0's prospects. The protocol has been very slow to come out, and its design is ugly, overcomplex, lumbering, and kitchen sink. It is nothing like its predecessor. MIDI 1.0 was pushed by a single person with a small coterie of contributors, and has the design elegance and simplicity of such. But MIDI 2.0 has been wasting away for years in a large committee, and reeks of it.
MIDI has only a few, fairly easily dealt with problems:
- It's too slow and has a fixed rate.
- Its time sychronization mechanism is primitive.
- Its data model is too low resolution both in value and parameter space, and workarounds (NRPN etc.) unacceptably trade off speed to fix this. The model also does not define constraints, such as min/max values or categorical labels for values.
- Its parameters are global rather than per-note (resulting in workarounds like MPE).
- Its escape mechanism (Sysex) is too flexible and leaves too many nonstandard design choices to the manufacturer. Because the CC/NRPN data model is bad, manufacturers often have resorted to layering custom and proprietary protocols on top of sysex, many of which are very, very badly designed, and all of which are different from one another. Indeed, some manufacturers have lately treated their corner of MIDI Sysex as a trade secret, using non-documented protocols (ahem Arturia) or profoundly stupid and lazy sysex protocol designs (I'm looking at you, Roli).
This stuff is easy to fix. But 2.0 goes far further, dumping in two-way communication protocol options, device queries, ties to existing, non-peer-to-peer protocols (USB) and lots of data models that do not appear to be separable from the basic stuff. What a hairball. Will anyone want to implement this?
Yes, cool things can be done with MIDI in browser, some that can't easily be done outside of browsers (such as synchronizing and overlaying on top of 3rd party videos, such as from YouTube). Here's some of the stuff I've been working on, mostly targeted at my kid, but adults love it too:
https://www.youtube.com/watch?v=khU5A6Y1dk4
(this one doesn't play on youtube because contentId flags it, but the app itself overlays on 3rd party YouTube videos and it is not a problem) https://www.karmatics.com/video/pianoplydemo.mp4
The Metaverse, coincidentally, is at nearly the same crossroads as MIDI in the early 1980's.
Each vendor built their own hardware and defined their own protocols. When Roland open sourced the MPU-401 chipset and gave away the MIDI specs, the industry blossomed.
Anyway, a lot to learn from MIDI... if Meta can similarly align an industry around basic hardware, APIs, and formats.
----------------------
USB midi is one of the worst thing that happened to MIDI. If I have a synth with USB midi and a controller with USB midi, I can't connect them to each other, which is idiotic and frustrating.
The original MIDI spec had its drawbacks, but the biggest have been addressed by MPE.
As for latency, jitter, granularity — as a gigging musician and producer, I've never had any issue with it. It's good enough. And most of the music you hear today is a reflection of that.
What's not good, it's that some manufacturers are ditching the 5-pin MIDI jack for USB or Bluetooth. Thanks, nobody asked. Same for losing the THRU port.
Because what musicians love is setting up their computer on stage while everyone is waiting, right?
Bidirectionality with MIDI can be achived by replacing the dual 5-pin MIDI with the mini-DIN (yes, the same connector the old PS/2 mouse used). Yamaha Tenori-On and and Reface series do that (though again, nobody asked).
And the entire NRPN space of MIDI is unused because it's unstandardized. So simply agreeing on how MIDI 1.0 should be used would address most of the problems that MIDI 2.0 claims to solve.
That's what MPE does, by the way, and that's why it has been silently becoming the de-facto standard.
The examples I see in promotional videos show a computer talking to MIDI 2.0 devices. We've had enough of that. What made MIDI 1.0 work is the simplicity of device-to-device connectivity, regardless of what the devices are (and whether one of them is a PC).
Think of this magic: if I have just ONE type of cable, I can connect ANY device to ANY OTHER device.
That means my Yamaha MX-88 I bought new last year can talk to Korg Poly-800 made before I was born.
I could have bought the cable in the 80s or yesterday, it's the same cable.
What MIDI 1.0 gave people is less thinking about how to connect devices, and more about making music.
USB midi did the same thing for devices connected to a computer, at the expense of being usable in a setup that does not have a computer. That implicit assumption — that everything will involve a computer — was flawed.
WTF, I want to use my ROLI to play my Yamaha — and I can't, because ROLI is too "modern" to talk to any hardware synth made the same year.
I hope that MIDI 2.0 avoids this fuckery, but I can't tell yet. Bidirectionality looks sus.
My litmus test is: if a device doesn't come with a 5-pin MIDI jack while having space for it, it's a gimmick (Teenage Engineering being an exception, because they make up for it with analog control: my pocket operators sync with my Korg Monologue via pulse, and Korg syncs with Yamaha over 5-pin MIDI).
And if Korg Volca could do it, so can pretty much everything else (hint: don't put it on the side, put it on the front panel if you want that slim look).
MIDI 2.0 can be a huge success if you wouldn't be able to tell a MIDI 2.0 device from a MIDI 1.0 at a glance; i.e. same connectors, same interoperability. Then it would be truly an upgrade, a 2.0, and not "thing that works like MIDI in some cases, but have fun buying dongles to connect old equipment to new gear".
MPE works on that model; and connectors aside, any multitimbral device is MPE-compatible.
This would allow easy connectivity with very low latency over normal LAN, including switches, power over Ethernet...
Disclaimer: I created a rtpmidi implementation for linux https://github.com/davidmoreno/rtpmidid
Technically that's not true. MPE adds a feature where you can dedicate a channel as a sort of "multicast" channel where any CC you send there affects all the other channels shared by the same instrument. If the synth doesn't support that it won't work. But it's possible to implement fallbacks that just do the multicast less efficiently from the controller.
I completely agree on USB though. It's awful that I can't just plug a USB controller into a USB synth.
(If there was going to be something to replace the old 5-pin DIN cables my vote would be for CAN-bus. It supports faster speeds, bidirectional communication, and can go pretty long distances.)
I know some people consider 3.5mm to be the devil‘s plug, but as a eurorack player I don‘t. I feel like MIDI on 3.5, now that the polarity is standardized, is really helping the good, USB-less MIDI stay relevant.
I'm absolutely loving MIDI on 3.5mm, just didn't see enough of it in the wild. Hope it catches on.
MIDI 2.0 sounds like a solution in search of a problem.
MIDI 1.0 addressed the problem of connecting any two electronic music devices to each other.
MIDI 2.0 seems to un-solve it.
So hopefully the lack of sales for MIDI 2.0 only devices will kill the protocol quickly.
The problems that MIDI 2.0 solves seem to be of the kind that musicians don't have, and definitely don't justify switching away from a simple three-wire connector that's the same on both ends (either 5-pin DIN or 3.5mm TRS which is gaining traction these days).
Here’s first search result: https://www.midiplus.com.tw/en/product-detail/USB_MIDI_HOST/
I know this full well.
So now, you need an extra device (MIDI host) to connect two devices, plus extra cables, plus power supply, and have fun if you need to set it up on stage in two minutes between the sets.
And good luck if both the controller and sound module are USB slaves.
The device you linked does NOT solve this problem.
Seriously, the only dongle I found that actually solves the problem is CME WIDI Master[1]
It's a 5-pin DIN - to - Bluetooth MIDI dongle that runs off MIDI power (i.e., just plug and forget).
Brings you from the 80s straight into 2020s with no noticeable latency, and no wires.
That's how I actually connect my newer controllers (with Bluetooth midi, which, thankfully, does not require the other device to provide power) to old synths.
Can highly recommend, 5/5, etc., but it's frustrating that I'd need to go through Bluetooth and a dongle for devices that could be linked with one short simple wire.
According to the specs which can be downloaded from midi.org there is no 5 pin DIN socket or 31kbit/s current loop anymore; the new Midi instead uses Ethernet and Wifi to connect "instruments". Apparently the protocol runs on UDP.
> As for latency, jitter, granularity ...
Well, maybe I play too fast or too many notes in a chord, but it happens quite often that I get an arpeggio instead of a chord.
Is there a universal MIDI router/multiplexer box with a whole bunch of USB and MIDI ports on it? If not, would there be a market for such a thing?
Nope. You can do this by plugging a USB hub into a computer/tablet/phone, and running several MIDI interfaces into the hub, so it's not an unsolvable problem for the musician, just a very clunky setup.
Didn't find a single device with multiple USB and MIDI in/out ports after an extensive search. And the devices that I did find cost more than the synths that they would connect.
>If not, would there be a market for such a thing?
There is a market for a compact device like that, especially if it can be battery-powered for live gigs, remembers the settings, and doesn't need a screen/external device to set up the routing.
Even something as simple as "Merge all IN ports, and send to all OUT ports" would be great, and there isn't such a thing.
Seems like most musicians who care about this simply don't buy gear without 5-pin ports to begin with.
But yes, I've been thinking about making this for years now, and if you need a startup/kickstarter idea - go ahead, I'll chip in.
For old MIDI DIN you would need a MIDI adapter or use the raspberry pi serial ports and some circuitry. Can be powered by an USB powerbank for example.
https://github.com/davidmoreno/aseqrc
I also added to the mix rtpmidi (https://github.com/davidmoreno/rtpmidid), and USB MIDI gadget (https://github.com/davidmoreno/midiconfigfs) on the PI, so then I can use the pi itself from one or several computers via Ethernet and USB.
All the MIDI host boxes I've seen only have one USB port, so can't be used to connect two UDB-midi devices to each other.
It does solve all the problems I mentioned, and yes, it's not the simplest device (and sadly, I can't say the high cost is unjustified).
Isn't that what USB-C is for?
Nope. USB is master-slave (aka host-device); two slave devices don't talk to each other (nor provide power).
USB-C just shoves this problem under the rug by making the cables look the same on both ends.
By breaking compatibility. Everything used to just work, now a layer of complication is added to the mix.
This is why we can't have nice things.
MPE solved some expressiveness and didn't break the world...
MIDI 2.0 has been out for awhile and as far as I know there aren't any mainstream products that use it. (Maybe one or two companies have dipped their toe in the water.) That doesn't bode well for the future of the protocol. Something like the Expressive-e Osmose one would think would be exactly the kind of instrument MIDI-2.0 is for, but nope, it's MPE. If you want an expressive controller, there's the Haken Continuum, the Linnstrument, the Roli Seaboard, the Osmose, etc... and they all work work with MPE.
https://www.expressivee.com/2-osmose
https://expressivee.happyfox.com/kb/article/162-will-osmose-...
To make OSC a suitable replacement for MIDI, you would have to come up with a set of OSC messages everyone can agree upon. That's not likely to happen...
The short story could be that the members of the MIDI Association chose to pursue their joint specification to be the next version of MIDI.
The actual story will have to be answered by someone who attended all of the various meetings that have occurred over the last three decades about what the MIDI 2.0 spec will be. I was only at a few.
I don't think MPE is the end of the road, though. It'll probably be replaced eventually by something that was designed from the start to do the kinds of things that MPE is for. I'm not entirely convinced that MIDI 2.0 is the MPE replacement I'm looking for. Maybe someone will just invent something entirely new.
(I have some thoughts in that direction that I plan on publishing eventually, not so much in the "hey look, here's a new protocol everyone ought to use" sense, but more like "if you were going to design a music protocol to do what MPE does but better, this is an example of what it could look like".)
But having 32 instead of 7 bits for pitch will give better pitch resolution, no? Or am I misunderstanding something?
If you really want to interface MIDI with a computer in a fashion consistent with the original MIDI specs, then you can use an actual Serial port at MIDI's 31,250 baud rate, which is possible to do on a Raspberry Pi for instance (or on a computer which you could set your baud rate to that). Then you can get interrupts precisely when the MIDI notes arrive.