An update to 37-year-old MIDI
1–10 of 105 posts
Re: An update to 37-year-old MIDI
#2Recent & related: https://news.ycombinator.com/item?id=22180731
Re: An update to 37-year-old MIDI
#3This seems to just be an articleized version of Adam’s excellent video from several months ago.
Re: An update to 37-year-old MIDI
#4This seems to just be an articleized version of Adam’s excellent video from several months ago.
Not a particularly informative or well-written one frankly.
"Also, with more memory, there are simply many more possible features that MIDI 2.0 can try to emulate. More memory should also reduce the chance of the timing between playing a MIDI instrument and digital recording to be slightly off. This should mean music played on MIDI 2.0 instruments will feel more analog, and make it possible for non-keyboard instruments to work better with MIDI."
Eh? What?
"The fact that MIDI 2.0 is bidirectional has two major effects. First, it means that it is backwards compatible, and won’t make the billions of MIDI 1.0 devices already out in the world obsolete."
No, backwards compatibility does not follow from MIDI 2.0 being bidirectional.
"“I think using a MIDI guitar would change the way I make music. The way our brain orients to making music on a guitar is just different to a keyboard layout. I used to have a MIDI guitar instrument, but I don’t have it anymore because I felt like there was a lot of latency and I didn’t really like the results I got. I am hoping [MIDI 2.0] will solve some of the issues I had before.”"
Well prepare to be disappointed. The problems with digital non-keyboard instruments has little to do with MIDI. In the case of a MIDI guitar, the latency problem is an issue of physics, not the digital transport.
Re: An update to 37-year-old MIDI
#5MIDI 2.0 is awesome and all, but I'd be happy if Firefox supported MIDI 1.0. (only Chrome and Edgium and the like do, Firefox has been saying they will for ages -- https://bugzilla.mozilla.org/show_bug.cgi?id=836897 -- and it seems to be extremely low priority)
Re: An update to 37-year-old MIDI
#6This seems to just be an articleized version of Adam’s excellent video from several months ago.
Can you link to the video?
Re: An update to 37-year-old MIDI
#7imho MIDI 2.0 hits the low hanging fruit but doesn't go far enough at fixing the biggest problem in professional audio. Deterministic rendering. Basically same input makes the same output, which doesn't happen even in totally digital systems - doubly so with live (or recreated) midi events.
I'll give an example - you have your PC with $DAW_OF_CHOICE running and plug in $MIDI_2_CONTROLLER to USB and enable a track and hit record, play your stuff, and stop. When you play it back, unless the cosmic forces are exceptionally on your side, it will not sound the same as when you played it. It's subtle and sometimes ignored or even desirable, but it's there.
There are a lot of reasons why this problem hasn't been solved, some technical and others artistic. But imho, a certain grade of equipment (namely, recording/reproduction, of which the MIDI protocol is a key component) should behave identically under the same conditions and be able to reproduce a performance exactly. It's a goal that borders on absurd, but I think we could do it!
Namely - enough of this "transport agnostic" horseshit. Give me a professional event protocol that is sent synchronously with the audio, on the wire and on the board. I want my codec chips interleaving midi messages (don't care if they're 16/24/32 bit) as a separate audio channel, even if it is undersampled (eg send LRLRLRMLRLRLRM over I2C at the appropriate clock to have audio in time and MIDI undersampled by 3x per word), I want MIDI events in my interrupt and in the callback, synchronized exactly to whatever audio is coming in at the same time.
And give me unadulterated total, absolute dictatorial control over the audio drivers using a ping/pong buffer that gets mapped to memory in the audio callback for my professional application and mine alone. Minimize the kernel time spent mapping physical memory to virtual memory, like ASIO drivers but without the bullshit. I want as little overhead between the frame buffer coming in off DMA to the chip as I want without the possibility of pwning the system. Hell, give me a dedicated core!
Re: An update to 37-year-old MIDI
#8MIDI 2.0 is awesome and all, but I'd be happy if Firefox supported MIDI 1.0. (only Chrome and Edgium and the like do, Firefox has been saying they will for ages -- https://bugzilla.mozilla.org/show_bug.cgi?id=836897 -- and it seems to be extremely low priority)
Audio apps should stay out of the browser
Re: An update to 37-year-old MIDI
#9This seems to just be an articleized version of Adam’s excellent video from several months ago.
Who is Adam?
Re: An update to 37-year-old MIDI
#10MIDI 2.0 is awesome and all, but I'd be happy if Firefox supported MIDI 1.0. (only Chrome and Edgium and the like do, Firefox has been saying they will for ages -- https://bugzilla.mozilla.org/show_bug.cgi?id=836897 -- and it seems to be extremely low priority)
Audio apps should stay out of the browser
Why?