Hacker News new | comments | show | ask | jobs | submit login

The use case originally was a single MIDI line [1] connecting all the keyboards in a studio. Most people couldn't afford more than sixteen keyboards/samplers/drum machines, so running everything through a single MIDI output made sense.

It didn't take long for multi-output MIDI interfaces to appear, but until they did everything went out of a single port, and the software worked to suit, with the channel setting on each track being used to select a playback device.

[1] Technically the single line went through multiple MIDI thru connectors. But it was still the same stream of information.




In addition to this, it's important to note that in a .mid file (or, more accurately, a Standard MIDI File), a track is deliberately quite similar to a stream of MIDI data. There are some changes, obviously (among other things, timing information is stored as a delta per-event, and the addition of Meta Events displace the MIDI Reset command) but all of these can be dealt with just before the events are sent out, to my knowledge.

Because events in a track in a Standard MIDI File are stored more-or-less the same way they'd be sent down the wire, that includes the channel information. The sender doesn't need to have any concept of channels in order to send the events stored in a SMF.

(Yes, this does mean that you can have notes on different tracks that are on the same channel. That's actually useful sometimes when using a DAW, especially for solos and drum parts.)


I've played around with various USB MIDI devices and while its possible to eg create multiple virtual devices, they tend to create one which simply streams a series of notes (with channel as part of the note).

MIDI messages tend to be 3 bytes[1]. For example, a "Note On" message is 0x9Z 0xKK 0xVV where 9 is the "Note On" command, Z is the MIDI channel (since its 4 bits, you can have 16 channels), KK is the key/note (up to 128 [2]) and VV is the velocity (up to 128 different values).

[1] excluding system messages and the channel pressure command which has only 2 bytes

[2] the most significant bit is always 0 for data bytes. If its 1 (like in the first of the messages byte) it is treated as a command byte.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: