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

51–60 of 105 posts

Re: An update to 37-year-old MIDI

#51

Post by vortico »

orangefarm wrote: post #49
vortico wrote: post #46

Earlier quoted context omitted.

Audio over internet would be at least 300ms latency, not sure where you're getting "10ms". Anything over 10ms is annoying, and 50ms is nearly unplayable.

Why would it be at least 300ms latency?

To send/receive a multi-channel audio/MIDI buffer to/from a server, you need to go through at least a dozen protocols, including waiting for the speed of light between you and your server. If you're in NY and your server is in LA for example, that's already 30ms gone just considering speed of light. Other factors multiply this latency by an order of magnitude.

Re: An update to 37-year-old MIDI

#52

Post by atoav »

kazinator wrote: post #38
core-questions wrote: post #25

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

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 will notice that the range of things between the most silent and most loud you can manage is usually huge. For midi controllers this is kinda limited, so good developement.

Re: An update to 37-year-old MIDI

#53

Post by orangefarm »

vortico wrote: post #51
orangefarm wrote: post #49

Earlier quoted context omitted.

Why would it be at least 300ms latency?

To send/receive a multi-channel audio/MIDI buffer to/from a server, you need to go through at least a dozen protocols, including waiting for the speed of light between you and your server. If you're in NY and your server is in LA for example, that's already 30ms gone just considering speed of light. Other factors multiply this latency by an order of magnitude.

Okay and you would say that if you optimised all of these factors you would end up with a latency around 300ms?

I just set my Ableton Live to 300ms and it was actually o.k. I think the reason is that a lot of people don't actually 'play' their instruments these days - at least in electronic music.

Instead, they program their drums by putting midi notes on the grid and then listening to the result. The same with synths etc. So when I work this way, the 300ms latency are actually bearable. Of course it would be different if I used drum pads to play my drums 'live'. But honestly I don't know many people who do that and when I watch tutorials on YouTube also almost no one is doing that. A lot of electronic music producers 'play' their instruments with their mouse button.

Re: An update to 37-year-old MIDI

#54

Post by atoav »

orangefarm wrote: post #44

Is there any reason why music production in the cloud isn't the standard yet? High-quality VSTs requiree a lot of CPU power. Even my 16-inch MBP easily heats up once I add some more advanced VSTs. I would rather pay X$ per month and have my music production work station in the cloud and interact with it from any old device with a fast internet connection. Working with a buffer size of 512 samples, I currently have a…

As a musician: what you say sounds nice on the marketing papers, but no thanks. Me and most of my collegues value reliability and owning the things they play with. Why? Because it is your damn instrument and it shouldn't change unless you like it to, and it should work anywhere even without internet. Something that needs a network connection to start up is dangerous, but something that relies on a decent internet connection is downright wrong. For home use — maybe — but for live use? Never.

Also 10ms more is already too much. If I had to decide between cool cloud synths and the latency I'd go for latency.

Re: An update to 37-year-old MIDI

#55

Post by duskwuff »

v-yadli wrote: post #40
core-questions wrote: post #25

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

> 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. I don't agree. Musical sounds are evolving, so one should not be s…

> Sure there are non-standard 14bit encodings

There's nothing nonstandard about 14-bit encodings. Pitch wheel and all of the standard controls are 14-bit.

Re: An update to 37-year-old MIDI

#56

Post by rzzzt »

kazinator wrote: post #38
core-questions wrote: post #25

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

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.

Re: An update to 37-year-old MIDI

#57

Post by rzzzt »

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…

You can distribute the values non-linearly, though; the difference between smallest and largest value might be big, but I don't think I could hit a pad or key in 128 different ways. Some controller software does offer a selection of velocity profiles.

Re: An update to 37-year-old MIDI

#58

Post by comboy »

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…

You could make similar argument against webgl.

Sure, it's hard, but take a step back and midi is just a more sophisticated keyboard/mouse (re input, the output is just a few pixels).

Most musicians are ok with as much as 10ms latency while playing. That's plenty of CPU time. 1ms is about how long it takes sound to travel 1 feet. So how far away you are from your speakers may give you more latency that whatever current CPUs are capable off.

I'm not arguing to make web DAWs and audio plugins. But for learning piano it's perfectly fine.

Re: An update to 37-year-old MIDI

#59

Post by vortico »

orangefarm wrote: post #53
vortico wrote: post #51

Earlier quoted context omitted.

To send/receive a multi-channel audio/MIDI buffer to/from a server, you need to go through at least a dozen protocols, including waiting for the speed of light between you and your server. If you're in NY and your server is in LA for example, that's already 30ms gone just considering speed of light. Other factors multiply this latency by an order of magnitude.

Okay and you would say that if you optimised all of these factors you would end up with a latency around 300ms? I just set my Ableton Live to 300ms and it was actually o.k. I think the reason is that a lot of people don't actually 'play' their instruments these days - at least in electronic music. Instead, they program their drums by putting midi notes on the grid and then listening to the result. The same with synth…

Access Analog (https://accessanalog.com/) is already doing something similar, and their system is around 300-2500ms latency (https://accessanalog.com/support/#1534876416634-f660a710-8f4...). A company cannot reliably offer much better than this latency, unless they have servers in all their customer's cities.

To most DAW users, 300ms is unacceptable, so any service that processes audio on a server needs to make this caveat very clear in their documentation. The problem with such a business idea is that local computers run DAWs just fine, so very few people would seek remote audio processing.

Re: An update to 37-year-old MIDI

#60

Post by vortico »

duskwuff wrote: post #55
v-yadli wrote: post #40

Earlier quoted context omitted.

> 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. I don't agree. Musical sounds are evolving, so one should not be s…

> Sure there are non-standard 14bit encodings There's nothing nonstandard about 14-bit encodings. Pitch wheel and all of the standard controls are 14-bit.

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't change.

- 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.

- DX7-style SysEx: Honestly this is my favorite, but because system exclusive messages are supposed to be... system exclusive, nothing else uses this standard (except for some DIY projects I've seen).

Post reply on HN