Live data from Hacker News

An update to 37-year-old MIDI

qz.com

101–105 of 105 posts

Re: An update to 37-year-old MIDI

#101
post #11

Earlier quoted context omitted.

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.

well, last I looked:

1) you could eavesdrop on events from instruments and you could publish midi events, but you could not actually register the browser as an instrument or an output that could be seen by the rest of the midi ecosystem

2) binary abstractions that are not very javascripty leaked up into the js objects. I remember seeing hexadecimal MIDI frames in my console that I had to decode myself- no other web API does that

Re: An update to 37-year-old MIDI

#102
post #11

Earlier quoted context omitted.

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.

it can be made to work, it is mostly not literally broken.

Re: An update to 37-year-old MIDI

#103
post #94
post #88

Earlier quoted context omitted.

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

Thanks!

Re: An update to 37-year-old MIDI

#104
post #48

Earlier quoted context omitted.

> 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. I'm sorry, but...what? I'm the rare non-professiona…

I wouldn't be at all surprised if the process is not bit perfect; the question is: can you hear a difference on your own? Can you hear the difference if it is pointed out ahead of time (through waveform comparison)?

I would be absolutely surprised if it weren't bit perfect.

We're dealing with 7 bits of MIDI data controlling, typically at most, 48,000 samples per second. These numbers are chump change for modern computers. The bit depths can add some more complexity to that in terms of dynamic range (I'm usually working at 32 bit float), but that doesn't apply as much to the situation here.

Yes, real-time performance is a tough task (as is always stated, "the audio thread waits for nothing"), but OP here is talking about recording MIDI data, which -- once recorded -- acts as a static input controlling either a synthesizer or sampler. So let's break that down.

A digital synthesizer, unless designed with some amount of randomness (typically for "analog-like" behavior purposes), by definition is the same every time. The MIDI data in this case is going to be something like CC7, controlling output volume; CC1, controlling some pre-defined parameter (i.e. opening/closing a filter); etc. A solid representation of OP's example in this case would be "CC7 controlling output volume of a synth over a 4 second period, linearly from totally silent upwards to 0 dB." I fail to see how that could possibly change from one playback to the next, unless, again, some amount of randomness-with-same-MIDI-data is a feature of the synth's programming.

A sampler is just, at its most basic form, playing back audio. Audio is a static file; MIDI is controlling which audio is playing back. Round Robin sampling, where, say, C4 is played N number of times and X number of similar samples are called randomly so as to avoid the "machine gun effect," where literally the same sample is called, could account for "it not sounding the same," but like the "analog-like" programming of the synth above, that's on purpose, not a flaw.

I routinely deal with situations where phase cancellation null tests would reveal the kind of behavior that OP is talking about, and I simply have never come across them. And that's not even going into sensitivity in listening, which while subjective and impossible to prove, is something I put a lot of faith in.

Sorry, unless OP can point me to a solid source laying out a further explanation, I call horse shit.

Re: An update to 37-year-old MIDI

#105

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…

> I currently have a latency of 11.6ms in Ableton. Adding another 10ms latency through the internet connection wouldn't be a drama for me.

Music is all about timing. Latency is crucial. 11.6ms is already too high for playing anything but instruments with slow attacks. Adding 10ms more would make it almost unusable for anyone that actually plays with their fingers.

What you describe could probably be used for musics that are programmed rather than played, but that's already a niche product.

Post reply on HN