[HN Gopher] How will MIDI 2.0 change music? (2020)
___________________________________________________________________
How will MIDI 2.0 change music? (2020)
Author : kelnos
Score : 92 points
Date : 2021-10-30 19:28 UTC (3 hours ago)
(HTM) web link (qz.com)
(TXT) w3m dump (qz.com)
| romwell wrote:
| As long as it's 100% backwards compatible, including the 5-pin
| DIN connectors, I'd be on board. No 5-pin, no game.
|
| More on this below.
|
| ----------------------
|
| 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.
| habosa wrote:
| This 100x. I am just getting into all of this hardware and it's
| so frustrating to need a computer in the mix just to get two
| pieces of otherwise wonderful single-purpose hardware to speak
| to each other.
| 112233 wrote:
| There is a dongle for that! They call it "MIDI host"
|
| Here's first search result:
| https://www.midiplus.com.tw/en/product-detail/USB_MIDI_HOST/
| romwell wrote:
| Oh fuck that.
|
| 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.
| 112233 wrote:
| And good luck finding something that plugs into your
| computer's type C port without another dongle! What a
| good time for making dongles we're living in!
| romwell wrote:
| You're going to make me cry :(
|
| 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.
|
| [1]https://www.cme-pro.com/widi-master/
| romwell wrote:
| Right?
|
| 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.
| spicybright wrote:
| One great thing about musicians is they're not forced into
| upgrading things as fast as computer software.
|
| So hopefully the lack of sales for MIDI 2.0 only devices
| will kill the protocol quickly.
| zozbot234 wrote:
| > 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.
|
| Isn't that what USB-C is for?
| romwell wrote:
| >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.
| moogly wrote:
| What about the venerable USB OTG?
| 112233 wrote:
| Like, can I connect two USB-C harddrives together to copy
| data? Usually (except when mentioned loudly by the
| manufacturer) USB midi devices are "device" devices, not
| "host" devices
| elihu wrote:
| > "MPE works on that model; and connectors aside, any
| multitimbral device is MPE-compatible."
|
| 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.)
| nitrogen wrote:
| _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._
|
| 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?
| kennywinker wrote:
| That'd be a midi host box. There are a few, tho mostly you
| run into issues of complexity - they require too much
| configuration to be useful / fun.
| romwell wrote:
| Yeah, and they _don 't work_ for the problem I stated:
|
| 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_.
| romwell wrote:
| >Is there a universal MIDI router/multiplexer box with a
| whole bunch of USB and MIDI ports on it?
|
| 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.
| dmoreno wrote:
| Not exactly what you are looking for, but I created a web
| interface for ALSA sequencer, which effectively makes any
| raspberry pi what you are looking for.
|
| 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.
| moomin wrote:
| I wouldn't hold your breath on MIDI 2 guitar controllers being
| better than MIDI 1. The fundamental problem is pitch resolution
| and that isn't really addressed by having a better protocol for
| representing pitch and intonation.
| rnestler wrote:
| > The fundamental problem is pitch resolution and that isn't
| really addressed by having a better protocol for representing
| pitch and intonation.
|
| But having 32 instead of 7 bits for pitch will give better
| pitch resolution, no? Or am I misunderstanding something?
| elihu wrote:
| MIDI 1.0 has 14 bit (per channel) pitch bend, which is probably
| fine. What MIDI 2.0 adds is per-note pitch bend, so you don't
| have to dedicate a separate channel for every string, which is
| awkward and un-idiomatic. (MPE at least standardized how
| multiple-channel instruments should behave, but that was a
| relatively recent development.)
| strenholme wrote:
| Now, I agree that MIDI 1.0 was designed for keyboard based
| synthesizers, and I know that complaints about MIDI latency have
| been around about as long as MIDI has been. So, yes, it has
| always been imperfect.
|
| 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.
| 112233 wrote:
| What happened to OSC?
| romwell wrote:
| The same thing that will happen to MIDI 2.0, I feel :D
| spacechild1 wrote:
| OSC hasn't really been designed as a replacement for MIDI, I
| think. It is really a generic data communication protocol. They
| only specified the syntax and omitted any _semantics_. As a
| consequence, each application has to specify their own OSC
| messages. And that 's what digital mixing consoles, lighting
| consoles, DAWs like REAPER or computer music programs like
| SuperCollider do. There really is no common ground between how
| these applications use OSC.
|
| 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...
| diskzero wrote:
| What happened, as in why isn't OSC "MIDI 2.0"?
|
| 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.
| nyanpasu64 wrote:
| Replying to a past comment
| (https://news.ycombinator.com/item?id=22188146):
|
| > - 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.
| bonestormii_ wrote:
| Yeah, articulation should be standardized in the midi
| specification. It's always a custom mapping to control it even
| when proper articulations are available. "Oh cool, custom
| mapping?!", you might say. Wrong. It sucks, because it tends to
| make old old scores utilizing articulation unusable because the
| mapping was stored in some obscure plugin configurations
| divided amongst many plugins.
|
| 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.
| dang wrote:
| Some past related threads:
|
| _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)
| sillysaurusx wrote:
| I just wanted to say, the next and prev links on comments are a
| brilliant feature. Thanks!
| frosted-flakes wrote:
| And the "root" link. But since they are plain links they
| pollute the History stack, which is a bit annoying.
| dang wrote:
| We're thinking about handling them in JS to avoid that. But
| other users want it the other way. Might have to do a poll.
| iainctduncan wrote:
| It won't. It will make certain small elements of music making a
| little easier, but there's nothing in Midi 2.0 that will
| fundamentally change what we can or cannot do in a way that will
| be noticeable in _music_ in a broader sense. Compared to
| something like the advent of cheap digital recording, VST
| plugins, of fast computers, midi 2.0 is a drop in the bucket.
|
| 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.
| timc3 wrote:
| You hit the nail 100% on the head there. I Couldn't agree more
| with what you have said hence the comment and not just an
| upvote.
| IAmGraydon wrote:
| Yeah I mean the feature that matters most is high resolution
| MIDI CC so we can finally avoid stepping. It's great, but long
| overdue and not really a game changer.
| rutierut wrote:
| There are a lot of claims in this article about MIDI1.0 that are
| misleading at best, it makes it sound more limited & crude than
| it is. Still it's indeed very nice to see some improvements here,
| especially since some were transitioning to proprietary
| communication protocols over HID.
| prox wrote:
| Of all technologies, I believe MIDI has been the most plug and
| play experience for me. Plug a midi cable in, boot up a sequencer
| and you are good to go. Really interesting to see what can be
| done with MIDI 2.0
| throw_m239339 wrote:
| That's all good up until you try to synchronize different MIDI
| devices with their own sequencers. Even "voltage triggering" is
| more accurate...
| em3rgent0rdr wrote:
| have you tried using
| https://en.wikipedia.org/wiki/MIDI_beat_clock
| TheOtherHobbes wrote:
| The clock is not very accurate and devices have to
| interpolate it. Which is something they all do slightly
| differently, especially if the tempo changes - which
| doesn't happen much in pop, but happens regularly in media
| composition.
|
| 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.
| em3rgent0rdr wrote:
| Midi can plug-and-play so easily because there is no
| handshaking. Every midi capable device has already agreed upon
| the 31,250 serial baudrate and 8-bit data + 1 stopbit format
| and the commands.
|
| 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.
| romwell wrote:
| And even that is not really a protocol problem. It's trivial
| for a device to implement "reset-on-disconnect".
| squarefoot wrote:
| The problem is that there is no such thing as a disconnect
| signal, so a device can't know a cable has been pulled or
| something in between has been powered off; if it happens
| then the device is left hanging with a note on, and one
| must find a way to send the relevant note off or the all
| notes off message when communication is restored. Adding
| such controls (aside the simple reading of the current loop
| value that doesn't solve all problems) would require one
| more layer which would translate in more complexity and
| more latency.
|
| 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.
| wtfrmyinitials wrote:
| I was trying to write a program using midi last year and was
| surprised by the lack of any libraries to work with it. Then I
| looked up the spec and was able to get all the functionality I
| needed with 10 lines of code interacting with /dev/midi.
| Incredible how powerful such a simple interface is.
| [deleted]
| odiroot wrote:
| Never mind what new features will come, I hope it'll always be
| backwards compatible with MIDI 1.0. MIDI today is so universal
| and so easy to understand, even on the very low hardware level.
| LegitShady wrote:
| Agreed. I have thousands of dollars of equipment using 5 pin
| midi connectors that all use current midi.
|
| 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.
| md8z wrote:
| I don't see why someone couldn't make an adapter from 1 -> 2.
| I think the other way around would be lossy and not
| desirable.
| pknopf wrote:
| I don't know how it would be if they are switching from 8 bit
| to 32 bit.
|
| I imagine most devices that come with MIDI 2.0 will have an
| option to run in either 1 or 2.
| Rochus wrote:
| The physical layer is completely different; Midi 1.0 was a
| current loop with DIN five-pin connectors; Midi 2.0 uses
| Ethernet and Wifi.
| LegitShady wrote:
| The physical layer is the easiest thing to get an adapter
| for. It's the logic and processing that is hard to make
| cross/back compatible.
| romwell wrote:
| >The physical layer is the easiest thing to get an
| adapter for
|
| 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_).
| LegitShady wrote:
| You're actually proving my point, rather than disproving
| it. Thanks, I guess?
| romwell wrote:
| What's your point? (And how do you define the physical
| layer?)
|
| 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.
| Rochus wrote:
| I don't think that the new 32 bit packet based protocol
| will run over the 31kBit/s current loop.
| supernovae wrote:
| MIDI 2.0 is going to have a tough road ahead of it to get any
| adoption.
|
| MPE solved some expressiveness and didn't break the world...
| throw_m239339 wrote:
| No, because most MIDI capable devices couldn't be bothered to
| implement the first version of the spec correctly even today.
| spicybright wrote:
| Do you have examples?
| wackget wrote:
| When XHR requests are blocked, the OP's URL returns a 404.
| "Interesting" website design.
| sharklazer wrote:
| MIDI 2.0 has USB as a pre-req. I'm not sure how this improves
| things. One of my chief complaints, and why I moved away from USB
| to an all-midi setup is how interrupts are handled, making USB
| sometimes unreliable, especially with large setups like mine.
| MIDI just works and is pretty easy to implement. I've never
| experienced a real limitation. Resolution has its workarounds but
| honestly isn't all that limiting.
|
| 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.
| sova wrote:
| Midi 1.0: 127 steps
|
| Midi 2.0: 4,294,967,296 steps
|
| https://www.midi.org/midi-articles/details-about-midi-2-0-mi...
| romwell wrote:
| Number big, protocol better!
|
| 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.
| jmull wrote:
| Yup. MIDI 2: solving problems musicians don't have and
| creating new problems! (Excessive complexity -- MIDI 1 was
| hard enough to implement. MIDI 2 is telling everyone to
| jump 10ft high -- good luck with that.)
| mrandish wrote:
| I agree that many of the things in MIDI 2.0 don't seem
| directly relevant to the bread-and-butter musicians,
| composers, mixers, producers and DJs who are the ultimate
| users. The numeric bumps in resolution, data and packets
| are all conceptually fine but it's not like they are
| addressing the standards gaps most holding back users and
| forward innovation.
|
| 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.
| capableweb wrote:
| > MIDI 1 was hard enough to implement
|
| 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?).
| nitrogen wrote:
| If you're using only one 7-bit CC (and not an MSB/LSB pair)
| to control a filter cutoff parameter that can range from
| 20Hz to 20kHz, it's not possible to dial in the exact
| frequency you want to match a particular harmonic.
| em3rgent0rdr wrote:
| On this matter I must say for playing music live that the 127
| steps provides a great deal of resolution. Good enough for me
| that I have never felt like my EWI's breath sensor was not
| fine enough or that my piano's touch sensor was not fine
| enough or that a CC knob didn't give enough resolution when
| turning slowly. Though if I listen closely to an isolated
| note I could tell there was a difference in loudness between
| two neighboring velocity steps, but probably couldn't tell in
| a live performance setting, and I would challenge listeners
| to see if they could tell the difference. I would say 127
| steps is "good enough" or almost is for practical
| purposes...But that is just my datapoint and opinion. (For
| comparison, the most common video format is YUV420, and that
| averages to 12-bits per pixel, and most screen monitors use
| 8-bits for each color.) Had MIDI used the top bit to flag an
| optional extra byte for resolution, then that would have been
| great.
| jchw wrote:
| Aside from increased resolution, one of the biggest
| improvements is MPE. It allows controlling parameters on a per-
| note basis. A side effect of this is making microtonal music
| significantly easier to express, since you no longer need
| multiple channels to do per-note pitch-bending. MPE support is
| already probably more robust than MTS (MIDI Tuning Standard,)
| although I could be wrong on that.
|
| 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.)
| romwell wrote:
| MPE is not a MIDI 2.0 improvement.
|
| 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).
| mrandish wrote:
| MPE also enables increased expressiveness that new kinds of
| multi-dimensional controllers such as the ROLI keyboards
| leverage (new kinds of MPE controllers are shown at
| https://www.midi.org/midi-articles/midi-polyphonic-
| expressio...). While MPE is part of MIDI 1.0, many synth
| manufacturers never bothered to support it since their MIDI
| implementations were basically considered a "solved" problem
| by product management. Many of them never even bothered to
| support polyphonic after-touch except in their high-end
| keyboards.
|
| 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.
| m-hilgendorf wrote:
| MIDI 2.0 is transport agnostic so it doesn't necessarily
| require USB, however USB is going to be the best solution for
| connecting many MIDI devices for awhile.
|
| 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.
| WhitneyLand wrote:
| What would you have recommended instead of JSON?
| m-hilgendorf wrote:
| I think JSON makes a lot of sense. It's just orders of
| magnitude more complex to parse into useful data structures
| than MIDI1, or any other part of MIDI2.
|
| 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.
| nitrogen wrote:
| It's weird to put variable-length text-based serialization
| formats into something that has to perform in realtime no
| matter what, on potentially limited hardware.
| jcal93 wrote:
| I'm in your camp on this one. The new features are neat, but
| MIDI 1.0 being stupid-simple is its killer feature to me. Plus
| everything from the last 30yrs supporting it is a big plus. I
| love that I can take my 1980s SuperJX and fit it right into my
| setup with brand new stuff, and a brand new DAW, and everything
| just works.
| md8z wrote:
| I don't know if I would call MIDI 1.0 simple in practice. It
| has a lot of really confusing idiosyncrasies, it's definitely
| got that feel of being a simple base that was organically
| developed and had tons of things piled into it over the
| years. The packet structure in MIDI 2.0 is a lot more...
| consistent, I guess is what you could say? I don't think you
| even need a state machine to implement it beyond the initial
| handshake.
| rkagerer wrote:
| My biggest problem with MIDI is the latency & jitter introduced
| by USB adapters (many computers these days lack a dedicated sound
| card or even the space for one). Does the new spec do anything
| about that?
| bitwize wrote:
| If you want MIDI without latency or jitter, you pretty much
| need an old Atari ST. USB isn't the only source of latency (and
| I believe MIDI over USB runs in a special mode that minimizes
| latency).
| em3rgent0rdr wrote:
| And to be pedantic, USB is not officially part of the MIDI
| spec, so that problem introduced by USB adapters isn't really a
| problem with MIDI per se.
|
| 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.
| 999900000999 wrote:
| The only issue I've noticed, and this might just be an iOS thing
| is devices would randomly disconnect, I know it's not good for my
| iPad but one day I found myself incessantly plugging in the
| adapter over and over again to try to get it to work. It's at the
| point where I'm tempted to go Bluetooth midi only when using my
| iPad from music Creation. Which prevents me from using my full
| size piano, first world problems
| SeanLuke wrote:
| I know that this article is meant for the general masses, but
| it's rather misinformed in nearly every sentence it utters
| regarding MIDI 1.0. That's a shame.
|
| 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?
| romwell wrote:
| Yes to all of this. MPE is good enough.
| matchagaucho wrote:
| The article fundamentally speaks to how industry standards led to
| a proliferation of synthesizers and collaboration within the
| music industry.
|
| 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.
___________________________________________________________________
(page generated 2021-10-30 23:00 UTC)