Winamp had plugins for formats not anticipated by the operating system.
Exactly my point. With the Winamp SDK gone, there won't be a go-to ABI for input plug-ins anymore.
So is Apple's bounce animation patent, which is just an animated implementation of the step response of an underdamped second order linear system which has been known about for centuries.
The novel part might have been the application of an underdamped second order linear system to the task of representing the edge of a scrollable area. User interfaces in the prior art had typically done so numerically (0% or 100%) or by having a box in a scroll bar reach the start or end of a range.
I think that we are seeing the fundamental collision between the "Freedom is good, freedom indistinguishable from Turing completeness is better!" camp and the "I've got a task to do here, Make It So." camp...
I've got a task to do here: play music encoded in a format not anticipated by the developer of the player included with the operating system. This format happens to include a music sequence and bytecode for an 8- or 16-bit virtual machine to interpret it, and it has been shown to fit half an hour of music in well under 100 KiB. Make it so.
It supports winamp plugins.
That solves some the original problem I posed. Two problems remain: I imagine that these plug-ins' installers are looking for an installed copy of Winamp into whose plug-in folder to install the plug-in. How will they recognize XMPlay as a plug-in host compatible with plug-ins made for Winamp? And once the Winamp plug-in SDK disappears, how will developers of new input plug-ins for XMPlay ensure that the XMPlay team approves their request?
supports a lot of formats
The only reason I've used Winamp in the past few years is that most of the players for music formats related to classic game consoles have been released as input plug-ins for Winamp. Does XMPlay support NSF (NES), GBS (Game Boy and Game Boy Color), SPC (Super NES), SGC (ColecoVision and Sega), GYM/VGM (Sega logged), PSF (PS1), USF (PS2), GSF (Game Boy Advance), and 2SF (Nintendo DS)? On the XMPlay page, I see "Game Music Emu input plugin", which covers the NSF, GBS, SPC, SGC, GYM, and VGM, but not PSF and friends. What worries me more is that the page also states a policy of making the input plug-in SDK available only to approved developers: "The input plugin SDK is currently available only on request. If you would like to create an XMPlay input plugin, please get in touch."
Because that would require the flash to do deduplication and know that the blocks were full of FF and so could be copy-on-write (and, in your scheme, block-level compression)
Block-level run-length encoding is exactly what I had in mind. This way more logical sectors can be packed into one 64-128K erase page. A sector that has been compressed into "0x00, then 4095 more of the last byte" is as good as TRIMmed. It needs to be done anyway for file tails.
for every bit a lossless compression algorithm shaves off one file, it must add to some other file
Pigeonhole principle. I'm aware of that.
Thus some files are actually made bigger than their size implies.
By about one byte, a marker that the sector is uncompressed. In a real file system, this overhead of one byte per sector is made up for by real files that contain real redundancy, such as the last sector of a file (or the only sector of a small file). On average, the last sector of a file will contain a run of half a sector's worth of $00 bytes. This and other cases where sectors can be compressed allow more logical sectors to fit into a single erase page.
The life of a repo man is always intense.