Implemented saving instruments into binary files.

[vsariola]

This implements saving and loading instruments into binary files and corresponding binary format for the instruments. The instrument binary has the four byte signature, that base64 encodes to "SBoxI". Additionally, there's a version number 1 and compression method 0. Currently the data is always uncompressed, because the files were smaller that way, but I kept the signature byte to support compression in future.

The save instrument button is next to the copy/paste instrument buttons. The instrument binary can be drag'n'dropped to the editor.

[vsariola]

The binary format for the instruments is now the way I imagine all binary formats will be (see #45), so this could be merged while waiting for a more complete set of binary formats to be implemented.

[mbitsnbites]

Thanks! Will have a look at this. I envision songs and instruments ("presets") being the most important entities. I'm thinking: if we ever make a database, local and/or server-side, what would you like to put in it (for sharing and for re-use). Songs and instruments seems like the natural answer.

Patterns and such would be more temporary (copy & paste) IMO. A really cool thing would be if you could open two SoundBox instances and easily being able to copy whatever (patterns, instruments) between these two instances. There are probably several ways in which you can do that.

[vsariola]

If patterns are encoded as base64 binaries in the clipboard, then the behaviour that you can copy-paste a pattern from one SoundBox window to another Soundbox window automatically follows!

[vsariola]

The most problematic aspect of the whole thing will be the clipboard; it seems that it is still today difficult to get it working reliably with all browsers. The best option is probably to use a library e.g. https://clipboardjs.com/

[vsariola]

I added an input box that, when focused, encodes the instrument as base64 string, and when changed, tries to decode the contents as an instrument. Achieves part of the desired clipboard functionality without any external dependencies or kludge hacks.

[mbitsnbites]

I started looking at the branch (I have a local rebased version), and overall I like it. I still have to go through the binary format and versioning/compression (which looks good upon first glance BTW).

However, the import/export text box (which is a good idea) doesn't really fit the UI. Especially if you have a MIDI device connected (things get too crowded and the layout is broken). I'm considering dropping that commit for now just to get the rest of the load/save into mainline.

[mbitsnbites]

About the import/export base64: There's already support for URL-encoded songs in the save/open dialogs, which is essentially the same thing. Perhaps we can come up with a combined import/export URL/base64 input element (e.g. at the bottom/top stretching the entire width of the UI?), and have a selection/dropdown for what to import/export (song, pattern, instrument, ...)?

[vsariola]

1. One option is to use window.prompt for the copying and pasting (https://stackoverflow.com/a/6055620), or making the "Save instrument" button popup a similar dialog as the "Save song", but with a focused input area with text selected. This would add minimal clutter to the UI. The "Save binary" button could be in the dialog box.
2. Pasting directly from clipboard does seem to be quite well supported (https://stackoverflow.com/a/6804718), so we could also capture paste events and interpret the base64 encoded string from it.

[mbitsnbites]

I would like that whatever is being copied/pasted is done so as a URL rather than a plain base64 string. That way you have one less step for "remote pasting" (e.g. open in another tab/browser, or minifying the URL and sending it in a tweet). Also, whatever is in the clipboard is universally recognized by pretty much any software.

[vsariola]

Let's keep this going; I think this is an important feature, so we should pay attention to get it right.

About copy-pasting urls: is there a risk that the user gets confused and pastes the instrument url to the browsers address bar, overwriting the song in the process? Or how often would you want to open just an instrument from your collection of instruments, with an otherwise empty song?

For songs, sharing as urls makes perfect sense as you would expect the current song to be overwritten when you open a new one. But that an instrument can trigger the same behaviour, I'm not sure.

[mbitsnbites]

Sure, there's a clear risk that a song gets overwritten by a single instrument for instance. However it should be quite safe, as you can always go back in the browser history. It's actually worse if you load a song or pattern blob/file via the SB UI when you thought that you were loading an instrument (at least without undo, or if the user is not aware of the undo functionality).

[vsariola]

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.

[mbitsnbites]

I like all of your suggestions! They are in line with my thoughts too.

Going even further, I'd like to start thinking in terms of "assets" (songs, instruments, patterns are all assets). I can easily see a browsable "gallery of assets" that you can drag'n'drop different things onto the editor, so you essentially treat all assets equally in the UI. This gallery could be an online living database that you can filter and search on tags, types and names etc.

In any case - I am going to pick the instrument loading/saving and format from your branch. Being the benevolent dictator that I am (grin), I decided to go with FourCC "SBxI" instead of base64 "SBoxI" (for consitency with the song format, and since I am old school). Hope that's OK.

[mbitsnbites]

The export/import part has now been merged. The ideas discussed in this PR are still valid but unimplemented, and should be moved to new issues/PRs.