Suggestion: implement binary formats for instruments/patterns/columns/effects

[vsariola]

Here's a suggestion, which takes some work, but would make SoundBox totally awesome, which is why I am willing to undertake it: implementing binary formats for instruments/patterns/columns and perhaps also effects.

I propose, that:
Step 0. License the export/import code under the same license as the player (i.e. slightly more permissive), in order to promote interop with future tools. Making a separate .js for the export/import related code would be anyway a good idea, as they don't feel they should be in "gui.js"
Step 1. In addition to the existing song binary, implement binary formats for at least instruments, pattern snippets, and column snippets. Each of the binary formats would start with a different four byte signature, and one byte code code compression method. I would recommend that the byte codes are chosen so that the base64 encoding of the four bytes looks something like "SBoxI" when the byte code is an instrument and so on.
Step 2. Implement current copy / paste routines so that they use the system clipboard, if available. When copying, the binary data is base64 encoded to the clipboard. When pasting, try to base64 decode the data from clipboard and act accordingly: if it's an instrument, replace current instrument with it etc.
Step 3. Tweet your instruments as base64 encoded strings! Send a full song to a friend using facebook! Store draft melody ideas in a text file! Store a library of instruments using an ordinary text file!

Discussion:

• How many binary formats are needed? I think we need one per each type of item that can be copied. At least: song, instrument, pattern snippet (contain width, height and pattern data), column snippet (contains width, height and column data; when pasted, overwrites the column data at location of the cursor).
• Do we need full column type, that when pasted, overwrites the current column data starting from line 0? I think it would be more logical that if there's no range selected when copying, the whole column data is copied and when pasting, it always pastes at the top left corner, instead of pasting at the current cursor location.
• Do we need a type that contains both effects and column data i.e. the whole contents of the pattern? When moving stuff from pattern to another, it would be nice to be able to copy both effect track and column data, but that requires rework in the GUI: when are they selected?

[vsariola]

Copied from #43:

1. Saving instruments as URLs is fine; instruments stay still less than 80 characters long, so they should fit nicely on any screen.
2. I propose we harmonize the logic for saving/loading instruments and songs. Thus, one "Open instrument" and one "Save instrument" button. Presets go under Open instrument! (I never liked the preset dropdown anyway). Under "Open instrument", there's also "Data URL".
3. I propose we also support pasting links directly using ctrl-v, without going to "Open Song/Instrument->Data URL". The "Data URL" boxes would guarantee support if the browser does not support paste events.
4. Both in song and instrument, when saving the URL, one extra click could be saved by presenting an input instead of a link in the dialog. The input could have focus and all text selected when the dialog opens.
5. Both in song and instrument, one click could be saved by giving the "Data URL" input focus when the dialog opens.
6. Another click could be saved by not using radio boxes to choosing a example song or a preset instrument. Clicking it opens it immediately. This way, choosing a preset would require equal amount of clicks as today. With the feature I implemented before ("Confirm before overwriting song"), the risks of overwriting a whole song are low. Even lower, if the undo feature goes mainstream. And today, it's already pretty easy to lose an instrument with the preset dropdown.