Hacker News new | ask | show | jobs
by PaulDavisThe1st 2329 days 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).

1 comments

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.

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.