4 ms·

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 missin

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 7y ago
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 7y ago
  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.
  - usrusr 7y ago
    It's not latency that GP was bemoaning, it's the sequential nature: two note-on measures cannot arrive at exactly the same time. If it was just constant latency, GP probably wouldn't mind (or criticize that, but it would be a completely different argument). Latency alone can actually be worse with real instruments because electrical signals easily outrun sound. (Nerve conduction velocity however is the worst of all, it's a wonder that we can function at all with that shitty data transmission)
    - PaulDavisThe1st 7y ago
      No serial protocol with "real time" semantics can ever deliver two events at the same time. To do that requires scheduling of events before they are due to occur. MIDI doesn't work that way, and probably never should. Even in highly time-aware percussionists, sensitivity to timing is way below the timing delays that MIDI causes (e.g. with note smearing in a chord).
      - usrusr 7y ago
        With a defined artificial latency headroom and a message parameter to (partially) override that latency it would be possible. With reasonable low maximum concurrency and a very high bandwidth/message size ratio the required extra latency could stay well within the range of centimeters at speed of sound (a very high bandwidth/message size ratio would certainly also lessen the cost of not taking that feature). The next roadblock on the way to truly concurrent chords would probably be controller readout. I know nothing about how those are typically implemented, but I strongly suspect sequential readout.
        PaulDavisThe1st 7y ago
        The existing spread for a typically chord (triad) is already not audible (despite the claims of some people who refuse to double blind test it). Changing MIDI to have "defined latency" is a fundamental re-engineering of the entire protocol.
deleted 7y ago
[deleted]
seandougall 7y ago
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.
- 6581 7y ago
  > 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. As long as you don't transmit anything else. When you have 16 channels with many note and controller messages, latency and asynchronicity between channels can become noticeable.
  - noizejoy 7y ago
    I remember using 8x8 midi interfaces to get around some of that - not just for the additional midi channels, but also to thin out the traffic for each connection. i.e. each midi channel would get it's own cable/connection. However that approach didn't work when I wanted to send 16 channels to a single (non USB) multi instrument sound device like my trusty JV-1080. It became an excuse to buy more synths! :-)

scarecrowbob 7y ago

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 7y ago
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.
- usrusr 7y ago
  It's not latency that GP was bemoaning, it's the sequential nature: two note-on measures cannot arrive at exactly the same time. If it was just constant latency, GP probably wouldn't mind (or criticize that, but it would be a completely different argument). Latency alone can actually be worse with real instruments because electrical signals easily outrun sound. (Nerve conduction velocity however is the worst of all, it's a wonder that we can function at all with that shitty data transmission)
  - PaulDavisThe1st 7y ago
    No serial protocol with "real time" semantics can ever deliver two events at the same time. To do that requires scheduling of events before they are due to occur. MIDI doesn't work that way, and probably never should. Even in highly time-aware percussionists, sensitivity to timing is way below the timing delays that MIDI causes (e.g. with note smearing in a chord).
    - usrusr 7y ago
      With a defined artificial latency headroom and a message parameter to (partially) override that latency it would be possible. With reasonable low maximum concurrency and a very high bandwidth/message size ratio the required extra latency could stay well within the range of centimeters at speed of sound (a very high bandwidth/message size ratio would certainly also lessen the cost of not taking that feature). The next roadblock on the way to truly concurrent chords would probably be controller readout. I know nothing about how those are typically implemented, but I strongly suspect sequential readout.
      - PaulDavisThe1st 7y ago
        The existing spread for a typically chord (triad) is already not audible (despite the claims of some people who refuse to double blind test it). Changing MIDI to have "defined latency" is a fundamental re-engineering of the entire protocol.

deleted 7y ago

[deleted]

seandougall 7y ago

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.

6581 7y ago
> 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. As long as you don't transmit anything else. When you have 16 channels with many note and controller messages, latency and asynchronicity between channels can become noticeable.
- noizejoy 7y ago
  I remember using 8x8 midi interfaces to get around some of that - not just for the additional midi channels, but also to thin out the traffic for each connection. i.e. each midi channel would get it's own cable/connection. However that approach didn't work when I wanted to send 16 channels to a single (non USB) multi instrument sound device like my trusty JV-1080. It became an excuse to buy more synths! :-)