MIDI 2.0 Prototyping

Discussion in 'General Music Discussion' started by Solodini, Jan 30, 2019.

  1. Solodini

    Solodini MORE RESTS!

    Messages:
    3,529
    Likes Received:
    378
    Joined:
    May 7, 2011
    Location:
    Edinburgh, Scotland.
    The link at the bottom of this post shows that the MIDI Manufacturers Association (MMA) and the Association of Music Electronics Industry (AMEI) are prototyping MIDI 2.0.

    "The MIDI 2.0 initiative updates MIDI with auto-configuration, new DAW/web integrations, extended resolution, increased expressiveness, and tighter timing -- all while maintaining a high priority on backward compatibility. This major update of MIDI paves the way for a new generation of advanced interconnected MIDI devices, while still preserving interoperability with the millions of existing MIDI 1.0 devices. One of the core goals of the MIDI 2.0 initiative is to also enhance the MIDI 1.0 feature set whenever possible."

    There's talk of it being 32 bit (as opposed to the current 7 bit. 128 stages up to 4,294 million.) At surface value this seems like more velocities than would be relevant, but it seems like it'll make for more integrated use of different articulations, picking techniques, notes fretted on different strings, harmonic types, picking locations, aftertouch, resonance; and equivalents for other instruments such as sticking techniques, different styles of stick, burying the beater, playing heel up, tonguing for wind instruments, better dynamics for crescendos/diminuendos et c.. Could also carry specific information of how complex time signatures are subdivided, perhaps?

    I'm quite excited to see what comes of it, eventually. What are you hoping for out of MIDI 2.0?

    https://www.midi.org/articles-old/t...industry-amei-announce-midi-2-0tm-prototyping
     
    Bloody_Inferno and c7spheres like this.
  2. sezna

    sezna undermotivated

    Messages:
    1,333
    Likes Received:
    607
    Joined:
    Jul 3, 2013
    Location:
    Seattle
    It'll be a while. They're at the convention essentially just hyping it up, but I think some misinformation might be spreading.

    There are multiple messages sent with each midi note "packet". There's the first byte containing the channel and whether a note is turning on or going off, there's the second byte which is the note itself, and there's the third byte which is the velocity.

    3 bytes adds up to 24 bits, while 32 bits is 4 bytes. It is unclear whether or not they are changing the last byte, the velocity one, to be 4 bytes on its own and increase the total packet size to 6 bytes? Or are they simply adding a fourth byte to the packet, allowing an extra parameter to be expressed?

    I have seen a few people on youtube talk about this already and they all seem to think midi just sends a single byte currently, and it is only velocity, and upping the transmission to 32 bits would change the velocity to be 32 bits in resolution. This is flawed as midi does not send only one byte currently, it does not only send velocity, and "32 bit resolution" in a packet doesn't mean each individual value has 32 bits of resolution.

    That being said, if they really are changing the velocity parameter to 32 bits, I would imagine it would be for reasons other than capturing human musicality with 32 bits of resolution, because human musicality doesn't even have 32 bits of resolution. It would probably be for engineering simplicity or compatibility with other types of protocols and cables.

    Edit: I would not be surprised if they want to change the pitch value to 32 bits, to capture microtonality or various intonations.
     
    c7spheres, Solodini and odibrom like this.
  3. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    It's been a while since I dug into how MIDI works, but if I remember correctly, a lot of values sent use a sort of variable-length value - where the size/resolution of the number in question differs depending on the information being sent. Seems strange to try to hold onto MIDI 1 - I get it, but at the same time I think that's very much a product of it's time. I feel like I'd prefer a whole new thing.
     
  4. sezna

    sezna undermotivated

    Messages:
    1,333
    Likes Received:
    607
    Joined:
    Jul 3, 2013
    Location:
    Seattle
    According to my limited research, they're not variable length, but the type of transmission can change what the other bytes mean. A tempo change message will not have a pitch value, for example, instead it represents a tempo (and I'd imagine both the velocity and pitch packets are used for tempo as one byte is not enough to express a wide range of tempos).

    The only things I can think of that are insufficient are perhaps the 31.25kbit/sec transmission speed (which would be easy to change) and the lack of ability to express movements in velocity, i.e. a long note that gets louder/crescendos as it goes. It could probably benefit from some various other extra parameters as well.

    What makes you say it is a product of its time? I don't disagree, just curious.
     
    Solodini likes this.
  5. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    There are definitely variable-length values in there, I just don't remember what they're used for. And it in itself is a sort of an example of what I mean. MIDI was designed for a specific purpose under certain constraints that don't really exist anymore. It used to be very important to transmit a small amount of data very quickly - things like trying to encode numbers in as few bytes as possible, or how you can put yourself into a state where you send a steam of values without having to re-send state change messages, etc. - but realistically there's no need for those optimizations when you're talking about USB3 devices and things like that, IMO. Making the new standard on top of the original one means that you have to continue to work within the constraints of how MIDI already works - as opposed to starting from scratch and saying what do we want it to do, what are our actual constraints, how do we make this work for everyone who would want to use this?

    Edit: An example is the delta time for midi events. These are variable length values.
     
    sezna likes this.
  6. sezna

    sezna undermotivated

    Messages:
    1,333
    Likes Received:
    607
    Joined:
    Jul 3, 2013
    Location:
    Seattle
    That is a very good point, and I did not think with that mindset at all. I do. however, think backwards compatibility is important here given how many MIDI 1.0 devices there are. Either that, or manufacturers are going to have to allow for a device to be configured from MIDI 1.0 to MIDI 2.0 if they want to appease all their customers, which they may or may not be willing to do.

    Additionally, those constraints may not exist anymore, but they also are probably not actively holding back MIDI 2.0 from being much more performant. Yes, they could reengineer it from the ground up and probably get a more streamlined protocol, but is that better than developing something backwards-compatible that already has wide support in both software and hardware? It would at the very least be bothersome for me to buy converters for all of my synth gear that is currently oriented around MIDI 1.0.
     
    Solodini likes this.
  7. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    I suppose what I mean is that I don't know that we need to replace MIDI 1. It's been around for longer than I have, and I've yet to run into something where the problem was MIDI. Creating a new standard doesn't stop the original from working either. There's no reason, for example, that a USB device couldn't implement MIDI, then be able to switch into a mode where it communicates via a different standard. We only lose backwards compatibility if people stop implementing things that support MIDI, or people intentionally rip MIDI support out of things that already have it.
     
    Solodini likes this.
  8. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    That's not to say there's no risk of new products being introduced that just don't use MIDI anymore - and that could potentially suck for people who have MIDI gear.
     
    Solodini likes this.
  9. sezna

    sezna undermotivated

    Messages:
    1,333
    Likes Received:
    607
    Joined:
    Jul 3, 2013
    Location:
    Seattle
    Yes, I can see some improvements being possible with MIDI 1 though, and if MIDI 2 is essentially an add-on pack for MIDI 1, I'm down. I agree that MIDI 1 does not necessarily need replacing.

    I do get annoyed when new standards are introduced over widely adopted ones. One example being USB C being a different physical port than USB 1, 2, and 3, and the problems that is causing. Or, as a programmer, every new non-compatible version of JS or Swift or something like that. So I have a soft spot for backwards compatibility.

    I also don't see that happening any time soon. MIDI is on everything (keyboard wise), and to not offer that on a product would hurt sales.
     
    Solodini likes this.
  10. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    The only reason I know about the variable length thing is that I recently-ish wrote a MIDI implementation for a game. It strikes me as a standard that would be challenging to expand very far without breaking existing implementations. Like you wouldn't be able to hand a MIDI 2.0 file to a MIDI 1.0 implementation and have it just work out of the box without some amount of translation inbetween. Especially if your implementation is as sketchy as mine haha.
     
  11. tedtan

    tedtan SS.org Regular

    Messages:
    4,749
    Likes Received:
    1,273
    Joined:
    Dec 2, 2009
    Location:
    Never Neverland
    I would imagine that MIDI 2.0 will be a different protocol entirely, as there is probably some way to send the message in such a way that a MIDI 1.0 device would respond within it's constraints, but a MIDI 2.0 device would read and respond within the constraints of the new protocol. I am not familiar enough with MIDI to say how that would be accomplished, but there is likely a way within the existing MIDI 1.0 protocol to allow for this.
     
    Solodini likes this.
  12. sezna

    sezna undermotivated

    Messages:
    1,333
    Likes Received:
    607
    Joined:
    Jul 3, 2013
    Location:
    Seattle
    The problem is that if the data stream varies at all from what it should be, the 1.0 device will interpret that as more MIDI data.

    Do they want to make it backwards compatible in such a way that MIDI 1.0 devices can read 2.0? Probably not, That would mean that all valid 2.0 streams would need to also be valid 1.0, so no, that is impossible. They must mean that it should be backwards compatible in the sense that 2.0 devices can read 1.0, which either means that MIDI 1.0 is a valid form within 2.0, or 2.0 can recognize it and adapt (which would be more on implementation's side than specification). Either way, this is all hearsay and I'm interested/excited to see what they come up with after the endless compromise and committee back-and-forth that will happen. There is also the chance they just said "high priority on backwards compatibility" and not "backwards compatibility" to just get more people on board, then the actual spec might deviate from that.

    Hm, I had no idea about the variable length values, but apparently it is part of the timestamp value. Thanks for the knowledge. I messed around with writing a MIDI driver once but it worked fine with uniform length time stamps, so I never came across this.
     
    Solodini likes this.
  13. JohnIce

    JohnIce Singlecoil Enthusiast

    Messages:
    5,197
    Likes Received:
    2,071
    Joined:
    Apr 4, 2009
    Location:
    Gothenburg, SWE
    One of the big talking points in the analog vs. digital synth world has always been that the 0-127 limit of midi CC's always results in audible stepping when using filters and automating parameters in various plugins. Higher resolution midi would enable digital synths and effect automations in a DAW to more closely emulate the smoothness of the knobs on an analog piece of gear. That's my immediate thought about all this. It might not be a huge deal if you're a guitar player or drum programmer, but if you're a synth head it's exciting news.
     
    Solodini and sezna like this.
  14. Andromalia

    Andromalia Pardon my french

    Messages:
    8,191
    Likes Received:
    2,270
    Joined:
    Dec 24, 2009
    Location:
    Le Mans, France
    Depends. On one hand, human velocity certainly has infinite resolution: admitting you strike a string at different speeds, the resolution is already infinite (there is an infinite number of decimals between any numbers). On the other, it's mostly lost on our ears whose resolution is finite: they can't make a difference between a 1 newton hit and a 1.0000000000000000000000000001 newton hit.
     
    Solodini likes this.
  15. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    I wonder if you could correct for this in specific cases, in the existing MIDI setup, by sending some kind of meta-data to signal that you want to interpolate between those steps instead of using them as-is.
     
  16. p0ke

    p0ke 7-string guitard

    Messages:
    2,391
    Likes Received:
    1,463
    Joined:
    Jul 25, 2007
    Location:
    Salo, Finland
    I'm not very familiar with midi (apart from having programmed a Behringer FCB1010 to do what I want on my Digitech GSP1101), but wouldn't it work such that if a MIDI1.0 packet is 7bits and MIDI2.0 is 32bits, the first 7 bits in a MIDI2.0 packet would be "legacy bits" which would work directly on a MIDI1.0 device and the rest get dropped? Or do midi packets not have any kind of <start> and <end> "markers" ?

    Or does midi actually work such that it waits until something is received and then just reads it 7 bits at a time? In that case, could a MIDI2.0 device send some kind of "are you midi2.0 compatible" handshake-packet and if it gets the correct response, start sending in midi2.0 format, otherwise proceeding in midi1.0 format? Of course that would require two midi cables to be connected, since they're always either in or out...

    Or hmmm, maybe that would in fact work :O If MIDI2.0 would be full duplex, both in and out being in the same cable, both would always be connected and it would be able to receive the response. And in case of a MIDI1.0 device it wouldn't get a response either way, because the device either wouldn't be able to respond at all or it wouldn't know how to respond...

    Sorry for n00bing around :lol:
     
    Last edited: Jan 31, 2019
    Solodini likes this.
  17. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    There's no end marker. In order to read MIDI back you basically receive things in order and have to assume things are going to be what you're expecting. So you might get a stream that's something like:

    - a byte to indicate what kind of message you're about to get
    - a byte to indicate how much data goes with that message
    - the rest of the data of that message.

    And then it would loop. The next byte you look at is assumed to be the type of the next message - so if you inserted something extra in there, that next byte would be interpreted the wrong way. Some messages are assumed to be fixed sizes.

    So your midi data might look like this:
    90 3C 7F 90 FC 7F

    This would be two note-on events (90) and the two numbers following each 90 are the note and velocity (7F being full velocity - all 7 available bits are set - 01111111).

    If you inserted extra data between the notes (say you wanted two bytes of velocity data instead of one), you might try to do that like this:
    90 3C FF FF 90 FC FF FF

    So you'd have Note on (90), the note (3C) and two bytes of velocity (FF FF), but since there's no marker, an existing MIDI implementation might just look at the extra FF where the second 90 would have originally been, and try to interpret this as a new message type instead.

    This example is technically wrong, I'm missing some pieces (there's time stamps in between the messages), but the idea is there. I think a more accurate version would be to write it as:
    00 90 3C 7F 00 90 FC 7F
    <time><note-on><note><velocity><time><note-on><note><velocity>
     
    Solodini and sezna like this.
  18. TedEH

    TedEH Cromulent

    Messages:
    9,349
    Likes Received:
    6,635
    Joined:
    Jun 8, 2007
    Location:
    Gatineau, Quebec
    Now that I dig more into it a bit, it does seem like the people working on this have a pretty clear idea of how to keep things compatible - using a mechanism to determine/negotiate what a device is capable of, and falling back on plan MIDI 1 if anything fails. When I have some more time, would be interesting to look farther into how this might work.
     
    Solodini, tedtan and sezna like this.
  19. sezna

    sezna undermotivated

    Messages:
    1,333
    Likes Received:
    607
    Joined:
    Jul 3, 2013
    Location:
    Seattle
    I should say theoretically there is infinite resolution but my intent was to say that we, in no way, could differentiate. So yeah, I guess our ears were what I was commenting on
    @JohnIce that’s also a good point but 32 bits is definitely overkill for that so I’m sure it’s not their only motivation.

    @TedEH props for the great write up, thanks for taking the time
     
    Solodini and TedEH like this.
  20. p0ke

    p0ke 7-string guitard

    Messages:
    2,391
    Likes Received:
    1,463
    Joined:
    Jul 25, 2007
    Location:
    Salo, Finland
    Figures... But yeah, like I speculated before, and you'd apparently found somewhere, it'd need to do some kind of midi2.0 "handshake" (maybe similar to what usb does) and if that fails, just do plain midi1.0.
     

Share This Page