Andrew Huang did the first one manually, as can be seen in the YouTube video linked on the front page. I figured I could write code to automatically do it even for people who didn't have the software to do it themselves.
I plan to add more features to AutoMIDIFlip - in particular, it'd be nice to have an optional feature to auto-shift the different channels up or down octaves in order to have them occupy the same sort of range as they did in the original MIDI, as that'd probably end up with more listenable tunes. (Bass notes become screechy notes of death right now.)
So far, AutoMIDIFlip is the only automatic MIDI flipper I know of that preserves everything about the original song except for the note positions. In other words, if you flipped a tune twice, then removed the 6 extra empty MIDI tracks that AutoMIDIFlip would have added (3 per run, basically just attributing AutoMIDIFlip so that nobody just runs a MIDI file through it and calls it an original), you'd end up with exactly the same file, hash checksums and everything. There are only three exceptions to this rule:
* If the original source didn't utilise MIDI's "running status" feature (which simply acts to reduce the file size by removing redundant information - more info at http://www.midikits.net/midi_analyser/running_status.htm), then the resulting file from AutoMIDIFlip will be smaller than the original. It'll still contain exactly the same information, however.
* For Format 0 MIDI files, AutoMIDIFlip will output a Format 1 MIDI file so that it can insert the empty attribution tracks. These tracks do not contain anything, and AutoMIDIFlip won't attempt to separate the file into tracks; you'll still just have one track containing all the data.
* If for some reason the input MIDI file has more tracks than are indicated in the file header, those extra tracks will not appear in the output file. This scenario should basically never occur; if it does, there's something wrong with whatever program generated the MIDI file.
I'm happy to answer any questions people might have!
Technically, it's probably GarageBand that's wrong here, but I've changed AutoMIDIFlip so that GarageBand should be happy.
What was happening is that the original file is a Format 0 MIDI file. Internally, a Format 0 file only ever has one track, so all the instruments have to go into one track. That's okay because in MIDI, the channel numbers are stored per-note, so it still manages to work out. Each channel can only play one instrument at a time, though you can play multiple notes at once.
It seems that when GarageBand opens a Format 0 file, it automatically splits out that one track into (I'm guessing) 16 tracks, one for each channel. It also sounds like GarageBand makes no distinction between tracks and channels, so you can only have one instrument per track.
Prior to the change I just made, AutoMIDIFlip would always set the format field in the header to 1, so that it would output a Format 1 file; this was necessary so that it could add the three empty attribution tracks to the file. Everything else should have worked as before, but when GarageBand opens a Format 1 file, it will keep the layout of the tracks as specified in the MIDI file rather than splitting them into channels.
Because of this, and because GarageBand doesn't have the distinction between tracks and channels, GarageBand was losing the instrumentation data that was in the original MIDI file.
I've changed AutoMIDIFlip now so that it doesn't set the format field differently; if you give it a Format 0 file, you'll get a Format 0 file back. Because you can't add more tracks in that kind of file, it will append a short attribution - "(auto-flipped with automidiflip.com)" - to the title of the song instead.
Again, thanks for the report!
Do you know why it's possible to have different channels on the same track in MIDI? It's kind of cool to save channel information per-note, but do people really use this to have multiple instruments on one track?
Like GarageBand, it seems most DAW associate a channel with a track and not individual notes. What was the use case originally?
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.
 Technically the single line went through multiple MIDI thru connectors. But it was still the same stream of information.
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.)
MIDI messages tend to be 3 bytes. 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 ) and VV is the velocity (up to 128 different values).
 excluding system messages and the channel pressure command which has only 2 bytes
 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.
There's a possibility you might be able to find TiMidity++ using brew.sh or similar. If you find it, you could try that - it's a command-line program, though. You'll also need a GM SoundFont to use it - you can find a list at http://www.synthfont.com/links_to_soundfonts.html . Note that the page links both to GM SoundFonts and single-instrument SoundFonts - you want a GM (General MIDI) one if possible, as that will have all the instruments included in General MIDI.
I've been looking for some good MIDI players for Mac myself as I know other people who are looking for them. I'll let you know if I come up with anything!
I was learning Beethoven's Appassionata sonata and there's a section where the right hand has a series of five-note arpeggios that gradually decrease in register until the left hand takes over and continues down into the bass (while the right hand takes a climbing melody that originally started in the left).
Those five-note arpeggios were really hard in the left hand. So the technique my teacher recommended was to basically play an inversion of the left hand pattern at the same time as the left hand was playing. So when the left hand started on a Db, the right hand started on an Eb an octave up, and then basically play a mirror version - mirrored by the physical key, so E vs C, Bb vs F#, etc.
It sounded like crap, but it was very effective - since the right hand is stronger, the left hand would basically learn from the right. Pretty quickly, my left hand got very strong at that pattern and it became one of my favorite sections of the movement.
Source: | Invertible CP: | MIDI flip: |
. . | ... | .... |
Voice A: . . . | Voice A: | Voice B: |
. . | .... | ... |
| | |
... | . . | . . |
Voice B: | Voice B: . . . | Voice A: . . . |
.... | . . | . . |
And overall, invertible CP is rather easy to apply in a composition (I do it all the time!)
Have a melody, discard all timing info, place/record melody by just tapping on the spacebar.
I wonder how synthesizer music sounds when it's all human timing.
Also inversion is a fairly common technique in writing developments so some fugues will sound quite similar.
The range is defined by the relationship to the key root, so you need to know the key to do this properly.
You can invert at other intervals, which creates inversion plus transposition. See e.g.
I was curious though, so I tried it out on the Für Elise example. Here's the unedited version: http://automidiflip.com/merge-experiment/furelise-merged.mid
As expected, it's rather horrible. I tried editing it so that they began on the same note but an octave down (as with Andrew's original video), but it wasn't much better: http://automidiflip.com/merge-experiment/furelise-merged-shi....
Actual MIDI files themselves? Mostly just used as a file format to share musical/rhythmic motifs or export between music apps, not as an end product in itself.
The MIDI protocol is still dominant in the professional field for which it was designed: controlling electronic musical instruments.
By "MIDIs" I presume you don't mean MIDI but rather so-called "MIDI Files" (SMF) and the "General MIDI" (GM) spec. This junk was originally designed for consumer-level products like Casio keyboards. General MIDI eventually devolved into the ghetto of cell phone ringtones and other trash. But don't confuse this with MIDI proper, which is a long-lived professional specification controlling often very sophisticated (and costly) devices.
Dave Smith -- largely regarded as the founder of MIDI, lamented this recently too. See 00:25 here: https://www.youtube.com/watch?v=RnemYKi8Tb4
We detached this comment from https://news.ycombinator.com/item?id=13558991 and marked it off-topic.