Sorry I deleted your other message by accident (“delete” is right next to “reply”, oops!)
I like your idea about run-length encoding, base64, and gzip encoding and I briefly played with it but I don’t think I can bring the length down to something reasonable. E.g. Base64 encoding of the required 864 bits is still 144 characters long. But please let me know if you find some clever solution, I don’t know much about compression to be honest.
Other people also asked about potential support for shorter and longer tunes. I’m tempted to add this at some point, but that would also make compression more tricky.
If only the Playdate had a built-in camera. Then it could simply scan a QR code or something. I have a feeling that the SDK will sooner or later have networking capabilities (e.g. for exchanging high scores), so at that point the doors will probably open up for some online tune exchange system.
Ah yeah the comment interface can be a little weird!
What I meant was like. Since you have patterns of on and off, and you’ll have way more off than on, instead of storing every storage cell, you’d store the distances between cells which are on and off. So for example, storing the pattern 000010000001 would be stored as the sequence {5,1,6,1}, or realistically since most of the time you won’t have two adjacent 1 cells, you could store it as 5,6, and use a 0 to indicate adjacent 1s (so for example 0000011000001 would be {5,0,5}). And there’s almost certainly a statistical distribution which could cut down further on the number of bits needed to store each of the numbers; it’d be a great application of Huffman codes, which I think I’d mentioned in the other comment.
gzip+base64 could also be pretty efficient but it’s not really optimized for bitwise storage like that; I mostly brought it up as being fairly easy to implement.
From a statistical perspective I totally agree with you. Most cases can probably be broken down to something very space efficient. Most songs in this representation are essentially a sparse matrix.
What makes the password approach less appealing to me personally is that you could still build pathological examples where you don’t save much with such a compression scheme. In other words, passwords would have a variable length and, in the worst case, are probably as long as the full tune (modulo some base64 encoding or something).
And it becomes less practical in case I implement the option to compose longer tunes.
Yes but those pathological cases only affect the people who are trying to share their unlistenable weirdness. :)
Personally I like the constraints imposed by the realistic music box length, and the only thing I’d like to see added is alternate tunings (which is something you see in commercial music boxes, where the spools have to be matched to tine sets and allows for harmonic minor and more interesting chord progressions).
Fair point :)
Alternate tunings/keys is something I’m interested in adding. I don’t know much about music theory (and surprisingly little about actual music boxes)—do you think it would be sufficient to add the other major and minor keys? Or should there be more fine grained control over which 18 notes are used for each song?
I think the ideal thing would be to let everyone choose all 18 notes on their own, yeah. With a C-major scale you can already get many of the most common modes just by transposing to a different tonic, but that doesn’t help with the ability to have chord progressions that go between modes (and also still doesn’t have any way of getting harmonic minor). Also having multiple adjacent half-step intervals is really useful.
