Hacker News Reader

Comment by Rochus | Hacker News Reader

> They have bajillions of notes but most of the notes are not audible

Good point; and if they would be audible the latency would have been unbearable, since the MIDI 1.x protocol only supports ~31kbit/s; each note requires 3 bytes for on an off each; so e.g. a chord with more than ~20 notes no longer sounds like a chord, but like an arpeggio; many expanders I had were even slower.

View on HN

I don't believe black midi can be played on normal instruments, it's mostly computer-based (barring the punchcard pianos). In fact even standard pre-black-midi software would probably crash when trying to open such files.

This is a good attempt at playing Rush E (8 hands): https://www.youtube.com/watch?v=qbEBrMZ-G_k

I love the whole arm technique to play the bars xD

The original black midi for comparison : https://www.youtube.com/watch?v=Qskm9MTz2V4

A piano has only 88 keys (if you play outside of those it doesn't sound like a piano anymore, even on a computer). And if you use more than one piano at the same time, all what happens is a phasing effect if more than one hits the same note at the "same" time.

The point is that if the MIDI file and the synthesiser in question are all on the same system (i.e. a VST in a DAW), no MIDI data transfer has to take place. So the data transfer limit in question isn't applicable.

Even if it's on the same system your piano still has 88 keys and you get either a loudness gain per key or a phasing effect when a key is played more than once per time. The only somewhat interesting effect (at least for some) might be that the generator hits its limits (usually 20 to 40 notes polyphony) and randomly decides which notes to leave out or prioritize. But this is out of control of the "composer" and likely not the intended effect.

I have a real piano capable of midi input here and there is no way I'm going to test the power supply and solenoid drivers by sending them that kind of data because I'm pretty sure that the designers did not anticipate this kind of use.

The article says they sometimes play them slowly and speed the recording up to the correct speed afterwards.

This would hit physical limits with MIDI 1.x, since you would then have to somehow transpose down the music (to correct for the transpose up because of the much faster playback speed) which would cause a greatly reduced quality (or not work at all) since the frequency range by MIDI expanders and audio equipment was less than 20kHz. And the auditory masikng caused by the ear sets yet another limit.

I think you're misunderstanding. The slow-motion screen recording video can be sped up to match separate non-realtime software synthesis of audio (using e.g. Timidity++). It can all be entirely software so there aren't physical limits to worry about.

Try to do that with a factor of e.g. 10 (you would likely need a factor of 1000 to cope with a "composition" of millions of notes) and observe the quality. The "physical limits" (e.g. Nyquist rate) also apply to the calculations done by a computer. To cope with the speed-up of slow motion to real-time you'd have to re-sample or transpose. Even with a very large sampling rate both of these transformations only produce useful results within narrow limits (less than an octave, i.e. factor two).

The quality will be essentially perfect. The wave file is rendered in software, as slowly as it needs to go. The rendering speed has nothing to do with playback speed, sampling rate, or frequency. Think of it like a ray tracer generating a few pixels a second and gradually building up the frames of a movie. You could generate one audio sample per second and save them to a file, and twelve hours or so later you'd have a 1-second long piece of 44.1kHz audio. There is no speeding up or resampling or transposition involved because the audio file was generated with the right sample rate (nothing to do with the generation/calculation rate).

I responded to the fellow stating "The article says they sometimes play them slowly and speed the recording up to the correct speed afterwards." which implies a change to the time scale. But also if you do a "perfect" non-realtime offline rendering Black MIDI is pointless; a piano has 88 keys; if you want to play thousands of notes a second then the only "benefit" you get is either a comb filter effect when the same note is triggered nearly the same time or a 3 dB gain (on maximum) if triggered exactly at the same time; there are easier ways to achieve this, even in real-time.

The benefit is you can create sample-accurate arpeggios, amplitude-modulated timbres, and other extreme and unplayable effects famously (over)used in tracker music.

You don't seem to have experience of what trackers can do. Essentially Black MIDI is rendered tracker music with a nice animated piano roll background.

On a slow system a render will take longer than real time. On a fast system it won't.

> You don't seem to have experience of what trackers can do.

Well, I'm a trained musician and use sequencers since Atari times; a tracker seems to be just a sequencer more geared towards people who prefer to enter numbers instead of playing; if so I would prefer something like csound or chuck; but I was more interested in live music the last few years; here is what I currently do: http://rochus-keller.ch/?p=1153

Thanks. Why one white shoe?

The white shoes are padded gym shoes to avoid hematomas.

Is there any software which actually does this properly? I've tried timidity, but it doesn't produce decently sounding output with the black midis I have.

It gets worse when you throw "controllers" in there, which will generate many MIDI events per second to model the twisting of a knob or movement of a slider.

Reply on news.ycombinator.com