[HN Gopher] MIDI 2.0, first major overhaul to music interface st...
___________________________________________________________________
MIDI 2.0, first major overhaul to music interface standard from
1983
Author : davio
Score : 135 points
Date : 2020-01-29 14:22 UTC (8 hours ago)
(HTM) web link (reverb.com)
(TXT) w3m dump (reverb.com)
| tartoran wrote:
| For me MIDI 1.0 served my needs. I may look into 2.0 if the need
| arises. It is however great to know that it will be backwards
| compatible:
|
| _MIDI 2.0 will be backwards compatible, meaning all new MIDI 2.0
| devices will be able to use and send MIDI 1.0 data. And if, in
| time, you create a hybrid setup of old 1.0- and new 2.0-equipped
| machines, your rig 's MIDI 2.0 models will interact together with
| the fresh capabilities of the new spec, while the MIDI 1.0 models
| will continue to work as they always have._
| wwweston wrote:
| This is the most important feature. MIDI lives in a context
| where the computing world's conception of obsolescence would be
| even more hostile to owners than it is now; decades old
| hardware is still used and loved, keeping it part of the
| protocol is key.
| _delirium wrote:
| Kind of strange. This seems to be intended for the case where you
| connect your devices with something like USB, not with physical
| MIDI cables, and use MIDI as just an event/messaging protocol on
| top of the generic data connection. And it's true that MIDI has
| some limitations in that setup. But for that use-case, Open Sound
| Control (OSC) already exists, and is supported by almost
| everything on the software side, plus a growing number of things
| on the hardware side. Why not just use that?
| fortran77 wrote:
| We have an organ in our office warehouse with 8 ranks of real
| pipes, and several dozen virtual ranks and it is MIDI
| controllable. MIDI does a poor job of mapping organs to MIDI
| messages. There's no good way to control stops (i.e., what stops
| are selected on which manual/pedal) and couplers without
| "overloading" a lot of the meta commands. And there's no way of
| defining which stops (which can be on any manual) are under
| expression. There's no way to represent a "tutti" stop, etc.
|
| And even for conventional "piano" instruments, which you'd think
| MIDI would work well for, it's lacking. It doesn't have pedal
| velocity or position (often the damper pedal is held at some in
| between position) and it doesn't have key position. Advanced
| "player" systems, like the Bosendorfer SE or Disklavier Pro
| overload other MIDI messages to account for this. Anyone who
| plays a real piano will see MIDI's problems.
|
| At the very least, every keyboard instrument like Organs and
| Pianos should be 100% controllable from MIDI.
| 6581 wrote:
| > It doesn't have pedal velocity or position (often the damper
| pedal is held at some in between position)
|
| It does have pedal position. Pedal data is transmitted as a
| control change message (e.g. CC#64 for damper) with a 7-bit
| data value. Many recent digital pianos support half-pedalling
| including transmitting and receiving the pedal position via
| MIDI.
| scarecrowbob wrote:
| Indeed, this is true.
|
| I've often been super frustrated by things that receive MIDI:
| they don't expose certain controls to CC, or they don't
| respond to multiple channels, or they don;'t pass certain
| information to the Thru port.
|
| But often what is frustrating is that it's do-able in MIDI,
| it just wasn't implemented well on the device.
| scarecrowbob wrote:
| That's super cool that you have access to a pipe organ. I spent
| a lot of time in my youth building a pipe organ with my dad and
| the church we went to. They are amazing instruments.
|
| I'm having a hard time understanding how you'd have a hard time
| implementing an organ control setup over MIDI. Like I get that
| there there is no specific tutti setting, but why couldn't you
| just have all the ranks be CC channels and then have the
| various settings be program numbers, so tutti then is jsut
| calling up the program with all the stops open?
|
| I do play a real piano, and I haven't been seeing problems with
| MIDI in the time I've been using it. Like, I've seen a lot of
| issues with piano synthesizer/sampler implementations... but
| the basic interface of the piano seems (at least to me) fairly
| easy to represent in MIDI...
|
| Can you help me out by describing what kinds of problems you're
| seeing?
|
| Like I say, could just be my own lack of experience, but you've
| bade me curious what I'm possibly missing.
| unlinked_dll wrote:
| I wish they would have removed SysEx messages. They cause way
| more trouble than they're worth, now that we have property
| exchange/profile configuration built into the spec.
| [deleted]
| dkersten wrote:
| What's the problem that SysEx messages cause? I've only limited
| experience with them (having used them only to send config data
| to a device, in a way that didn't need the device to keep
| functioning while being updated, from a programming point of
| view, I found them quite convenient and simple, except perhaps
| the fact that you only get 7 bits per byte so may have to pack
| the data).
| unlinked_dll wrote:
| I can't know how big a SysEx message is until run time, which
| makes buffering them somewhat complicated when you don't know
| what's _in_ the SysEx message.
|
| This isn't uncommon in serial protocols, but MIDI has been
| lifted several layers above the UART it was designed for, and
| one of its strengths for everything _but_ SysEx is that you
| exactly how big messages are going to be and preallocating
| space for them is trivial.
| aikah wrote:
| > I can't know how big a SysEx message is until run time,
| which makes buffering them somewhat complicated when you
| don't know what's in the SysEx message.
|
| That's the reason why you want to break compatibility with
| MIDI 1 spec? Really? Just like for an HTTP stream, you
| don't need to know how big the stream is to process it,
| just when it ends, there is no new problem to solve here.
| unlinked_dll wrote:
| No, I want there to be only one way to do something in
| the protocol and to remove arbitrary binary exchange,
| this is one pain point. It turns your "standard" into a
| Frankenstein's Monster of data exchange, and you'd think
| we'd have learned over the last few decades that
| ambiguity in specification of a communication protocol is
| just going to lead to headaches and incompatible/buggy
| hardware.
|
| It's also weird to say SysEx is needed for backwards
| compat with MIDI 1.0. You can just require a translation
| layer between MIDI 1.0 sysex and MIDI 2.0
| configuration/property exchange for backwards compat.
| Opaque binary as a part of the protocol does not
| encourage compatibility among hardware.
| aikah wrote:
| The MIDI spec was successful for 30+ years for a reason
| and manufacturers managed with SysEx without any issue,
| there is no justification for any "compatibility layer"
| whatsoever here. The problem wasn't the spec obviously.
| SeanLuke wrote:
| [For the benefit of HN: SysEx is a special manufacturer-
| specific MIDI message which is undefined, so a synth
| manufacturer can use it for whatever he wishes]
|
| I build a lot of open source patch editors for older
| synthesizers. My beef with Sysex is that every manufacturer
| uses completely different approaches to defining their own
| proprietary messages with it. For example, nearly every synth
| in the universe has a sysex message for dumping a patch (a
| full set of parameter settings) from a synth to another or to
| a computer; but they define their messages is radically
| different ways, so I must construct an entirely different set
| of parsing and emitting tools for _every single synthesizer_
| , even within a given manufacturer. It's a nightmare.
|
| So continuing this example, if the MIDI association had
| gotten together early on and said that MIDI dumps _should_
| have a header that looks like THIS and then all the
| parameters in order, two bytes per parameter with no bit
| packing whatsoever, no two 's complement, and end with a
| specific checksum, then I'd have written 10x more patch
| editors so far. I wouldn't have to write custom parsers and
| dumpers: I'd just provide a list of parameters and their
| bounds.
| fit2rule wrote:
| (Disclaimer: been working in synth industry for decades
| now..)
|
| Most SYSEX dumps are just dumps of the plain ol' structs
| that the synth engines are using to drive their output. A
| lot of synths don't have the processing power to do more
| than just dump the struct.
|
| So, it wouldn't really make much sense to have them all use
| the same struct - this can't be enforced too well. Forcing
| synth mfr's to all use the same struct means that, even if
| they have their own internal plain-old-structs, they'd need
| code to dump the SYSEX according to the standard.
| SeanLuke wrote:
| > Most SYSEX dumps are just dumps of the plain ol'
| structs that the synth engines are using to drive their
| output. A lot of synths don't have the processing power
| to do more than just dump the struct.
|
| I don't think it's processing power: it's stingy RAM
| utilization. Many bad actors (Kawai, Casio, later Yamaha)
| did crazy bit-packing of parameters rather than just keep
| them in a simple array, while the more sane (Oberheim,
| E-mu, Waldorf, early Yamaha) at least tried to pack in a
| consistent way. Other bad actors (ahem Korg, as late as
| 2000) decided to use, shall we say, creative parameter
| encodings, going even so far as embedding textified
| versions of parameter numbers into sysex byte streams.
| And many used all sorts of crazy schemes for banks and
| patch numbering, most of which are incompatible with one
| another.
|
| And it's not just encoding: basic synth patch dump
| features are missing from different models. There are
| five basic tasks that most synth editors require:
|
| - Change patch - Request a dump from working memory -
| Dump to working memory - Dump to patch RAM and save -
| Send a single parameter change (for any parameter)
|
| Manufacturers couldn't even agree to make machines which
| supported all five of these. Some machines (Yamaha) have
| no way to write to RAM. Some machines couldn't do single
| parameter changes. Some machines can't properly change
| patches in a consistent manner. Some machines have no
| patch request mechanism. Many machines can't dump to
| current working memory: only to patch RAM!
|
| The situation is only getting worse. Whereas in the past
| manufacturers at least attempted a complement of sysex
| messages, now many manufacturers can't even be bothered
| to allow access to their machines (Korg, Roland). Others
| treat their sysex messages as proprietary secrets
| (Arturia, Digitech, Alesis).
|
| There is only one truly good, shining actor in the open
| MIDI spec space, and that is Sequential. Which shouldn't
| be a surprise given who runs it.
| 8bitsrule wrote:
| Lots of 1.0 instruments have only SysEx to load/save patches. A
| single patch may have hundreds of parameters. Whole libraries
| of patches exist; they can be loaded/saved at once with Sysex.
| So, no way.
| unlinked_dll wrote:
| I don't really see why that matters for a new protocol that
| fallbacks to MIDI 1.0, it's not a superset of MIDI 1.0. If
| your device only takes MIDI 1.0 SysEx for patches, anything
| that would send those patches via MIDI is going to do it on
| top of the fallback.
|
| What I'm saying is a new MIDI 2.0 device probably shouldn't
| be able to use SysEx. Either opt out of MIDI 1.0 and use the
| paradigms established or fallback to MIDI 1.0 and its
| limitations. Otherwise we're just going to get a mess of
| different implementations, and MIDI 2.0 will fail to be a
| successful standard.
| fao_ wrote:
| There's a standard? I googled a few weeks ago and obviously my
| google-fu was terrible because I didn't find a standards document
| for it
| AndrewDucker wrote:
| https://www.midi.org/specifications-old/item/the-midi-1-0-sp...
| robin_reala wrote:
| But nothing seemingly available for 2.0?
| nemacol wrote:
| "...the new specification hasn't been fully ratified by the
| members of the MMA and the AMEI, many details and
| implications of the new spec are still unknown."
| PascLeRasc wrote:
| https://www.midi.org/articles-old/details-about-
| midi-2-0-mid...
|
| The actual spec sheet is yet to be released, but this is a
| really great article about it.
| jacquesm wrote:
| Midi works fine for anything keyboard based. As soon as you
| deviate from that it becomes an exercise in frustration.
|
| Much better article:
|
| https://www.midi.org/articles-old/details-about-midi-2-0-mid...
| robin_reala wrote:
| Not that I'm familiar with the subject, but this article[1]
| suggests that Roli's Seaboard would need MIDI >1.0 to transmit
| per-note pressure and pitch bend info, and the Seaboard is
| definitely keyboard based.
|
| [1] https://reverb.com/news/roland-unveils-first-midi-2-ready-
| ke...
| PascLeRasc wrote:
| Pitch bend has been on MIDI controllers since forever, more
| or less. I'm super excited for this synth though, with per-
| note pitch-bend and multiple instruments reacting to key
| pressure: https://www.youtube.com/watch?v=UjZ6SuWxBFg
| 52-6F-62 wrote:
| Coming from strings, that makes so much sense. Learning
| some keyed instruments I always found myself attempting to
| bend/vibrato in that way without thinking.
|
| Also, that man looks a lot like Garth Hudson...
| https://pbs.twimg.com/media/DjtfCgOUwAA6K7o.jpg:small
| fit2rule wrote:
| MIDI 1.0 supports polyphonic pressure and aftertouch messages
| - just not a lot of keyboard manufacturers supported it,
| since its pretty processor intensive - not to send, but to
| sense...
| [deleted]
| sneakernets wrote:
| I'm so glad this happened, this may put an end to the many, many
| bespoke midi implementations I've come across.
|
| I participated in a piano competition over a decade ago (I
| believe it was sponsored by YAMAHA) which recorded all
| participants through an extended MIDI format that increased the
| resolution and bumped almost everything up to 1024 max from 127
| max. With MIDI 2.0 this wouldn't even be required, all the
| functionality is included.
| elihu wrote:
| > I'm so glad this happened, this may put an end to the many,
| many bespoke midi implementations I've come across.
|
| Maybe it will, but I'm not terribly optimistic that we'll avoid
| the scenario where the various manufacturers implement the
| parts of MIDI 2.0 that they care about, and we'll have another
| mess of partial implementations that aren't entirely compatible
| with each other.
|
| It might help if someone puts out an open-source highly
| portable reference implementation that everyone can use rather
| than every manufacturer writing everything from scratch.
| PaulDavisThe1st wrote:
| This quote from the section on the Capability Inquiry:
|
| "The type of instant-matching that is, as of now, still based on
| proprietary messages between Ableton hardware and software (or
| similar systems from other companies) will instead be universally
| available through MIDI 2.0"
|
| is misleading. The "matching" between (say) Live and a Push 2 are
| not based on proprietary messages sent between them, but merely
| on both ends knowing which messages to send. That's why an open
| source DAW like Ardour can also interact with a Push 2, in the
| same "instant-matching" way that Live can.
|
| Since MIDI is an open protocol, it is _always_ possible to
| determine what messages are being sent. The capability inquiry is
| a good idea, but it doesn 't replace the sort of carefully-built
| match between the hardware controller and the software that
| already exists.
| Jamwinner wrote:
| I am hopeful, but skeptical.
|
| All you musicians who can't feel the MIDI 1.0 delay need to play
| on some accoustical insturments and get what you have been
| missing. That couple of ms between each note make every chord a
| rapid appregio, drum hit a flam, and it gets worse as control
| data (much less sysex!) is added.
|
| While I was hoping for a timing-agnostic standard, what we seem
| to be getting is not terrible from what I can see. Does anyone
| have a link to an actual spec sheet or prototype implementation?
| scarecrowbob wrote:
| I wish my timing was that good. I've been using MIDI for
| decades and not ever noticed it when stuff was setup correctly.
|
| I mean, I play guitars and pedal steel, banjo, dobro,
| accordion, etc. all acoustically (or, more likely, "in the
| analog domain"). Maybe I just need to practice more or listen
| harder.
|
| Do you have any suggestions on how I can improve my timing
| and/or hearing to experience this?
| RuleOfBirds wrote:
| Ya. As someone who plays acoustic piano, guitar, ukulele, and
| ocarina...using MIDI 1.0 to connect my electronic gear hasn't
| created any latency that's noticeable to me.
|
| Sure if you're sending things to and back through a DAW or
| whatnot it can get noticeable, but that's processing/software
| time, not MIDI 1.0.
|
| I can't tell the difference between a 320kbps mp3 and FLAC
| either, but I'm not worried about it.
| [deleted]
| seandougall wrote:
| Back of envelope: With running status, a note on message is two
| bytes on a 31250 baud connection. That means the latency from
| transport is on the order of half a millisecond. If you're
| feeling latency, it's in the gear, not the protocol. MIDI
| implementation quality has long been wildly inconsistent, and I
| don't see a reason to believe that will change with MIDI 2.0.
| arexxbifs wrote:
| Damn, this means my Atari will become obsolete.
| lioeters wrote:
| For me, one of the highlights is the higher resolution of values,
| for example for control messages, from 7 bits (0~127) up to 32
| bits.
| kazinator wrote:
| What will Midi 2.0 mean for musicians?
|
| I suspect: frustrations with shit not working with other shit,
| like it used to with MIDI, and a big decrement in DIY
| hackability.
|
| USB is in the mix! Pretty much `nuff said, but I will say it
| anyway. USB is a complex beast with documentation that is a good
| fraction of a foot high, if printed out in all its versions on
| standard letter sized laser paper. If you bring that into any
| standard, that is now part of your standard.
|
| USB connectors do not have the optical isolation of MIDI current
| loops; USB interconnecting will bring in noisy ground loops that
| will have musicians and recording engineers pulling out their
| hair.
|
| The clever thing in MIDI is that a device which sends messages
| over MIDI to another device drives current pulses (not voltage).
| These current pulses activate an octo-coupling device in the
| receiver such as a phototransistor. There is no galvanic
| connection between the devices; they don't share any ground or
| anything.
|
| All sorts of talented musicians have done incredible things with
| MIDI. The resolution of MIDI has been just fine for people with
| real chops. MIDI 2.0 isn't going to solve the real problem:
| talent vacuum.
| exabrial wrote:
| MiDI 2.0 is not isolated? Crap. Literally any of my guitar
| pedals when connected by USB instantly injects noise into my
| electric guitar signal chain, and isolated USB hubs are
| practically non-existent.
| Polylactic_acid wrote:
| USB midi is already a thing though. And its a real pain to use
| if you want to connect 2 devices together where one of them
| isn't your computer.
| ipsum2 wrote:
| From the article:
|
| > When you connect devices together, the Capability Inquiry
| will immediately determine what each instrument is able to do:
| Your new MIDI 2.0 controller will automatically know which
| pieces of your rig are equipped with MIDI 1.0, which are
| capable of 2.0, and tailor its messages accordingly.
|
| So hopefully backward compatibility Just WorksTM.
___________________________________________________________________
(page generated 2020-01-29 23:00 UTC)