Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update to 37-year-old MIDI

qz.com

Post reply on HN
Print view View original

21–30 of 105 posts

Re: An update to 37-year-old MIDI

#21

Post by unlinked_dll »

jerrysievert wrote: post #18
unlinked_dll wrote: post #7

imho 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…

> 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! why should this always be the case?…

It's not about quantization error (which is quantifiable as noise) or the kind of nonlinearities you're talking about, but timing concerns.

It's basically the difference between naive automation in a DAW and sample accurate automation, it's not about the granularity of your changes but the fact that sample accuracy allows your system to reproduce the same thing every time. Not so many years ago, online renders in certain DAWs were perceptually and quantifiably different than offline renders because of things like this - you want to be able to tell a user what they hear while they work is the same when they go back and render.

With MIDI 1 and 2.0 that's rather difficult when factoring in live input due to the fact that your production system has wack drivers on top of a non-realtime OS and can't provide guarantees. MIDI 2.0 goes a good step in the direction with synchronization, but I have doubts that it will be utilized to where we can guarantee received events are replicated accordingly, due to the accuracy of reception and synchronization of clocks. Maybe we'll get it, idk.

Re: An update to 37-year-old MIDI

#22

Post by asveikau »

unlinked_dll wrote: post #8
robbrown451 wrote: post #5

MIDI 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

Web interfaces for video and voice calls are pretty good because I never particularly want to install somebody's conferencing app.

Of course that has nothing to do with midi.

Re: An update to 37-year-old MIDI

#23

Post by unlinked_dll »

nine_k wrote: post #17
unlinked_dll wrote: post #13

Earlier quoted context omitted.

Because "the audio thread waits for nothing." Garbage collection is unacceptable, more than a single pointer dereference to get to state is borderline unacceptable, and synthesizers (that an MIDI system would trigger) are up there with some of the most computationally demanding software you can develop even for toy projects. Especially so, even. A naively coded soft synth in C++ talking directly with drivers can easi…

A midi event stream is massively less demanding than a waveform stream. A browser could at least be a source of such events that you would route to your favorite hardware synth. Interestingly, browsers are capable of native audio and video playback for years; somehow it wasn't such a problem, given their relaxed requirements for latency.

It's because streaming video and audio is simplex, MIDI + rendering is duplex. Round trip latency for a decent app needs to be sub 5ms, it doesn't matter if you have 200ms+ for receiving packets from a video/audio source on a web page, since you're not providing live input to get live output.

Re: An update to 37-year-old MIDI

#24

Post by jerrysievert »

unlinked_dll wrote: post #21
jerrysievert wrote: post #18

Earlier quoted context omitted.

> 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! why should this always be the case?…

It's not about quantization error (which is quantifiable as noise) or the kind of nonlinearities you're talking about, but timing concerns. It's basically the difference between naive automation in a DAW and sample accurate automation, it's not about the granularity of your changes but the fact that sample accuracy allows your system to reproduce the same thing every time. Not so many years ago, online renders in cer…

> Not so many years ago, online renders in certain DAWs were perceptually and quantifiably different than offline renders because of things like this

and how has moving from 7 bits to 32 bits helped with this? rendering the changes in values across 32 bits is going to take a bit more cpu power than doing it across 7 bits. that's not really relevant here.

moving from 7 bits to 32 bits allows for smoother transitions - which is fantastic, but remember that the sound coming out is the culmination of a lot of different factors: having more bits doesn't change the 1+1 behavior.

> With MIDI 1 and 2.0 that's rather difficult when factoring in live input due to the fact that your production system has wack drivers on top of a non-realtime OS and can't provide guarantees.

great, so adding possibly more instability. I guess that's a "change", but probably not unless the underlying protocol is changed - otherwise no real changes: indeterministic results. and I think I'm ok with that.

midi 2.0: great, but don't expect much different - the music world has moved beyond midi (again), it should be interesting to see how midi adapts past 2.0.

Re: An update to 37-year-old MIDI

#25

Post by core-questions »

> In MIDI 1.0, all data was in 7-bit values. That means musical qualities were quantized on a scale of 0 to 127. Features like volume, pitch, and how much of the sound should come out of the right or left speaker are all measured on this scale, with 128 possible points. This is not a lot of resolution. For some really sophisticated listeners, they can clearly hear the steps between points.

This is extremely misleading. Sure, the velocity input into your synth is going to be at 7-bit resolution, but at soon as the synth has it, it can play anything it wants at whatever volume it wants to based on how you have configured it. There's nothing about the external 7-bit implementation that is really limiting the dynamics of the synth itself.

Higher resolution timing and a greater amount of 'awareness' about the features of the device at the other end so as to facilitate automatic mapping of controls from surfaces to synth parameters is what I would find more useful.

Re: An update to 37-year-old MIDI

#26

Post by tachyonbeam »

jes5199 wrote: post #11
robbrown451 wrote: post #5

MIDI 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)

that API is such a mess, though.

The web MIDI API? What do you dislike about it? It's pretty straightforward and easy to use.

Re: An update to 37-year-old MIDI

#27

Post by [deleted] »

unlinked_dll wrote: post #13
monetus wrote: post #10

Earlier quoted context omitted.

Why?

Because "the audio thread waits for nothing." Garbage collection is unacceptable, more than a single pointer dereference to get to state is borderline unacceptable, and synthesizers (that an MIDI system would trigger) are up there with some of the most computationally demanding software you can develop even for toy projects. Especially so, even. A naively coded soft synth in C++ talking directly with drivers can easi…

[deleted]

Re: An update to 37-year-old MIDI

#28

Post by robbrown451 »

jes5199 wrote: post #11
robbrown451 wrote: post #5

MIDI 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)

that API is such a mess, though.

Works for me. I'm able to connect a piano / midi controller to a computer, and have it work with a musical web app in Chrome.

Admittedly, I don't do much other that get the notes played on the keyboard (MIDI code, time down, time up, and velocity).

Don't need much more than that to do a whole lot of interesting things.

Re: An update to 37-year-old MIDI

#29

Post by unlinked_dll »

jerrysievert wrote: post #24
unlinked_dll wrote: post #21

Earlier quoted context omitted.

It's not about quantization error (which is quantifiable as noise) or the kind of nonlinearities you're talking about, but timing concerns. It's basically the difference between naive automation in a DAW and sample accurate automation, it's not about the granularity of your changes but the fact that sample accuracy allows your system to reproduce the same thing every time. Not so many years ago, online renders in cer…

> Not so many years ago, online renders in certain DAWs were perceptually and quantifiably different than offline renders because of things like this and how has moving from 7 bits to 32 bits helped with this? rendering the changes in values across 32 bits is going to take a bit more cpu power than doing it across 7 bits. that's not really relevant here. moving from 7 bits to 32 bits allows for smoother transitions -…

I'm not arguing with you, just agreeing in a different way :D

Nonlinearity is fun. I'm a big fan of it, and have spent a lot of time on the DSP side developing NLP that can be predictable and repeatable, and all the garbage associated with making it sound good.

My issue is more that MIDI 2.0 goes towards part of the issue - e.g. if I press N keys at the same time, N messages should be stamped at the same time and be able to be rendered by the synth at the same time - but I'm doubtful that systems will be able to handle this in a deterministic way, both in recording the incoming messages and replicating them in the same way the performer intended while playing.

Post reply on HN