Open emoon opened 5 years ago
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. WSBR
+ 4-byte version number, as we described above.
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 https://github.com/emoon/HippoPlayer/issues/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
WSBR
4 byte tag + a 4 byte value (for example a xx.xx.xx.xx semantic version would work here)