Add version in file header #4
Comments
|
I doubt plain semver would make sense for file formats, though. What's does for instance a patch-version mean there? |
|
It would only be for matching the tool it was saved with but I guess it's not needed. |
|
I really dig this; it's hardly any overhead, and would allow at least a version mismatch to be detected in hippo and our standalone player. It can also be trivially skipped by our official player example (and what we ship in intros). While distributing binary exports of our tunes isn't really a use case we've considered so much, I see no reason why we couldn't do it, especially since we already have this functionality in our StandAlonePlayer. One thing to note (as we discussed already) is that even with a small header, a player such as hippo would only be able to support songs that are made with the official set of devices we that we ship out-of-the-box. This rules out songs made with WS forks (which I hope are abundant actually; I'd love for people to make their own devices and go nuts) but I think that's a natural tradeoff and something we can happily ignore. As for whether or not the version should be semver, there probably isn't much value beyond a simple counter that we bump whenever we change the format. |
|
Similar to the player case, if a demotool wants to integrate with several synths and only wants to look at binary data, it would be useful for it to include such a header. So in that case we'd want a tag + version, i.e. |
…om Maj7 chunk. some code cleanup. The primary justification for the WSBR0001 header is issue #4. Any external players that want to detect/read a WS song blob can now have a method of doing so, with room for format versioning. So it's really not used within the WS codebase, but useful for players to understand the chunk. Nothing in the WS code is actually reading/parsing/reacting to this value. I have chosen to use a character based version ("0001" instead of uint8_t[]{0,0,0,1}), because it can be read in a text editor easily, and is unlikely to lead to problems. If versions do eventually exceed this, it can be adapted (hex -> other format -> extend the header, etc.). Apologies for yet another megacommit littered with changes of various relevance.
Something that would be useful would be for the (binary) files to have a version header. I would like to add WaveSaber playback support to HippoPlayer/HippoPlayer#60 at some point and in order to make sure that files are playable it would be good to be able to check a version of the file to ensure the player is new enough to play the format. Talking with @yupferris a suggestion would be ta have a
WSBR4 byte tag + a 4 byte value (for example a xx.xx.xx.xx semantic version would work here)The text was updated successfully, but these errors were encountered: