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

91–100 of 105 posts

Re: An update to 37-year-old MIDI

#91

Post by boomlinde »

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

There are many applications for MIDI that don't necessarily involve rendering audio in the browser. Most useful I've found are various patch editors for hardware synthesizers. I've also experimented with using MIDI for camera control applications, where you'd traditionally use some expensive joystick.

Another application is exactly the opposite of what you fear: offload audio rendering of some musical data to a well-optimized software synthesizer or a hardware synthesizer, via MIDI.

Re: An update to 37-year-old MIDI

#92

Post by boomlinde »

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…

MIDI addresses a broader category of problems where there might not necessarily even be an audio stream.

Not unusual now, I have an analog desktop synthesizer module with a MIDI-to-CV control interface, and I simply want to connect a MIDI keyboard to it to be able to play it. My application is unconcerned with digital audio streams. Actually, I have a bunch of synthesizers, some analog and some digital. I use a hardware sequencer to sequence them. Some use their own internal sequencers, so they simply use the start/stop/clock real-time messages to stay on beat. The point at which any of this becomes an audio stream is if I start my PC and record from the mixer output.

MIDI 2.0 at least opens up to some improvements to synchronization with fine grained event timestamps. Using that together with timestamped audio buffer delivery at least allows for jitter mitigation.

Re: An update to 37-year-old MIDI

#93

Post by vortico »

boomlinde wrote: post #90
vortico wrote: post #60

Earlier quoted context omitted.

For completeness, there are a few 14-bit MIDI control standards that I'm aware of, and all of them have major disadvantages. - MPE pitch wheel: You can only have 16 controls with this method. Otherwise, it's an efficient protocol. - NRPN/RPN: Requires 4 MIDI messages to send a single value in a proper way (control number, MSB, LSB, NULL control number). Technically you can do it in 3, or 2 if the control number doesn…

> - CC MSB/LSB: Plows over normal CC messages so you need to explicitly set up your controller / synth to agree with each other. As far as I know the order of MSB/LSB is not defined by any standard, and IMO this makes it a broken standard. It's well defined. The MIDI 1.0 spec says that the range of controller numbers 32 through 63 is reserved for optional LSBs for the corresponding controller numbers in the range 0 t…

Your quote doesn't specify the order of LSB and MSB messages sent by controllers. Nowhere in the standard does it specify the order.

The issue is this: If MSB arrives first, you'd want to reset the LSB to 0. If LSB arrives, the value will exist with a 0 LSB for some time duration. This creates bad value jitter. A possible solution (on the synth side) is to hold the MSB in temporary memory until LSB arrives. But if the controller sends LSB and then MSB, this won't work. So you have to deal with the value jitter.

This was brought up at the committee 40 years ago and they decided "eh, not worth it, the jitter's fine." But it's not.

Re: An update to 37-year-old MIDI

#94

Post by vortico »

v-yadli wrote: post #88
vortico wrote: post #60

Earlier quoted context omitted.

For completeness, there are a few 14-bit MIDI control standards that I'm aware of, and all of them have major disadvantages. - MPE pitch wheel: You can only have 16 controls with this method. Otherwise, it's an efficient protocol. - NRPN/RPN: Requires 4 MIDI messages to send a single value in a proper way (control number, MSB, LSB, NULL control number). Technically you can do it in 3, or 2 if the control number doesn…

I'd also like to mention that MIDI 1.0 runs on a 31250 baud/s com link. This requires a balance between precision and throughput. The bandwidth gets pretty tight with CC messages interleaved with clock and SYSEX (sample dumps, patch/pattern updates), that in a DIY sequencer, we have to do pendulum SYSEX updates to avoid disrupting the timing. Care to elaborate the DX7 sysex? Most newer manufacturers have a long ID so…

Sorry, it doesn't look like it's 14-bit, my mistake. https://github.com/asb2m10/dexed/blob/master/Documentation/s...

Re: An update to 37-year-old MIDI

#95

Post by beagle3 »

rzzzt wrote: post #56
kazinator wrote: post #38

Earlier quoted context omitted.

Also, if we talk about the volume parameter. The human ear's dynamic range is about 120 dB, which includes about 20-30 dB of pain. With 127 bits, we can map that with 1 dB resolution. 16 bit audio ("CD quality") only has a 90 dB dynamic range. We would almost never want a single instrument to have a 90 dB dynamic range, but if we did, MIDI values could logarithmically encode it with a better than 1 dB per step resolu…

You get 7 bits with MIDI, not 127 bits. Also noone wants to encode audio samples using MIDI; the last time someone (ab)used a volume control for digital sample playback was on the Commodore 64.

That's not true ... http://www.4front-tech.com/pguide/midi/midi8.html describes the standard.

Those of us who were using MIDI in 1990 fondly remember it taking too much time, being not well supported, and generally not working well. "No one wants to" is true, but 30 years ago, many people did want to.

Re: An update to 37-year-old MIDI

#96

Post by boomlinde »

vortico wrote: post #93
boomlinde wrote: post #90

Earlier quoted context omitted.

> - CC MSB/LSB: Plows over normal CC messages so you need to explicitly set up your controller / synth to agree with each other. As far as I know the order of MSB/LSB is not defined by any standard, and IMO this makes it a broken standard. It's well defined. The MIDI 1.0 spec says that the range of controller numbers 32 through 63 is reserved for optional LSBs for the corresponding controller numbers in the range 0 t…

Your quote doesn't specify the order of LSB and MSB messages sent by controllers. Nowhere in the standard does it specify the order. The issue is this: If MSB arrives first, you'd want to reset the LSB to 0. If LSB arrives, the value will exist with a 0 LSB for some time duration. This creates bad value jitter. A possible solution (on the synth side) is to hold the MSB in temporary memory until LSB arrives. But if th…

I understand the problem you describe, but it has nothing to do with the order of MSB/LSB being undefined.

The spec, again on page 12, says that upon receipt of an MSB message, the internal understanding of LSB should be reset to 0, so you can't set LSB first if your intent is to set both. If you want to set both MSB and LSB of a control, you have to send MSB first. If you are expecting both MSB and LSB, according to the spec, you can expect them in that order.

What actually prevents the value jitter mitigation strategy you describe is that you don't have to send the LSB in the first place. Controllers and synthesizers could here manually agree via configuration that the LSB will always be sent so that your mitigation strategy would work, or there could be a low-pass filter on the effect of the control to minimize the impact of value jitter for consecutive MSB+LSB changes.

Re: An update to 37-year-old MIDI

#97

Post by ciwolsey »

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

MIDI isn't audio. That was easy to refute.

Re: An update to 37-year-old MIDI

#98

Post by marpstar »

lightedman wrote: post #37
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)

I might be hallucinating memories but I'd swear my old MIDI website from 2005 worked perfectly in FireFox, including playing them.

WebMIDI goes beyond just "playing" a MIDI file as audio. It allows you to use MIDI as an input as well as understanding of the SysEx messages that can be used.

Re: An update to 37-year-old MIDI

#99

Post by lightedman »

marpstar wrote: post #98
lightedman wrote: post #37

Earlier quoted context omitted.

I might be hallucinating memories but I'd swear my old MIDI website from 2005 worked perfectly in FireFox, including playing them.

WebMIDI goes beyond just "playing" a MIDI file as audio. It allows you to use MIDI as an input as well as understanding of the SysEx messages that can be used.

I said "including playing" however. Back then, MIDI was handled by the OS, so it didn't matter if your browser supported it or not. All you did was send the raw data to the website's (admittedly crappy since my coding sucks) editor and you had your MIDI track laid down. Adjust quantization, adjust timing (because obviously you aren't doing this realtime back then) and you were golden.

Re: An update to 37-year-old MIDI

#100

Post by kazinator »

atoav wrote: post #52
kazinator wrote: post #38

Earlier quoted context omitted.

Also, if we talk about the volume parameter. The human ear's dynamic range is about 120 dB, which includes about 20-30 dB of pain. With 127 bits, we can map that with 1 dB resolution. 16 bit audio ("CD quality") only has a 90 dB dynamic range. We would almost never want a single instrument to have a 90 dB dynamic range, but if we did, MIDI values could logarithmically encode it with a better than 1 dB per step resolu…

The perceptability of the 128 steps depends on the parameters it influences. If the midi parameter influences e.g. some form of pitch, 128 values won't get you very far without having the steps perceived. It also has to do with the pressure range of midi controllers: 128 steps are few if you have to distribute them between "barely touching" and "hammering on it with full force". When you play a real instrument, you w…

If you want high resolution pitch, then you basically disagree with the whole concept of MIDI. The concept of MIDI is that notes are symbols. MIDI tells an instrument to play A4, not to play note witha 440 Hz fundamental. MIDI doesn't care how that instrument i tuned. A4 could come out as 430 Hz.

That said, MIDI supports microtonal effects like pitch bending. Pitch bend messages use 14 bits.

Post reply on HN