Closed marwin89 closed 7 months ago
marwin89
commented
9 months ago To get things started. What about this? Please add or correct 🙏
#VERSION: 0.1.0
#TITLE: Title of the song
#ARTIST: Name of the Artist
#MP3: Filename auf the audio file.mp3
#COVER: Covername.jpg
#BACKGROUND: Background.jpg
#VIDEO: Video.mp4
#GAP:12.4
+Normal Notes
+Golden Notes
+Freestyle Notes
+Rap Notes
+Golden Rap Notes
EOut of scope for this version: duet, medley, vocals, instrumental, etc.?
Baklap4
commented
9 months ago I'd define version 0.1.0, but also treat every file without a #VERSION tag to be 0.1.0. This should be mentioned somewhere
Maybe @bohning can include the new tag upon downloading through USDB_Syncer, maybe that AnimuxAlex can include it for every txt file on the server
As for bare minimum i'd only include the header tags:
Things like covers and backgrounds are all optional
for the notetypes i'd say:
Because the others are also both optional
Then from this version on. We'll have 2 more versions within the 0.x series: 0.2.0 -> Introduce the tags we currently have 0.3.0 -> Deprecate tag tags we don't wanna use 1.0.0 -> Removal of deprecated tags and final list of currently used tags 1.1.0 -> First new features we want to introduce etc....
marwin89
commented
9 months ago Here is a new spreadsheet table page for us to organize the versions. edit as you like:
marwin89
commented
9 months ago Updated format version spreadsheet: 📝
🔗 Versions Overview Spreadsheet
Please mind: release date of format versions and implementation date are different things. You decide when the new versions are implemented in your software
Nianna
commented
9 months ago The spreadsheet is a nice idea but it would be nice if it contained all information and was a single point of truth. Now by looking just at it I feel like I'm missing half of the info that is probably spread over various issues here on github.
Could you please add info why the tags were deemed deprecated and why others were renamed? For example I don't see why we would want to rename #MEDLEYENDBEAT to #MEDLEYEND? Is there any gain in that?
Also, what are the new tags supposed to mean? e.g. #ONLINE ?
Nianna
commented
9 months ago I'd define version 0.1.0, but also treat every file without a
#VERSIONtag to be 0.1.0. This should be mentioned somewhere Maybe @bohning can include the new tag upon downloading through USDB_Syncer, maybe that AnimuxAlex can include it for every txt file on the server
But why? Can't we treat version 0.2.0 (using excel numeration) as default version? None of the songs right now have #VERSION tag. But many of them do have tags like #GAP, #VIDEO, #COVER. Treating the files as files in version 0.1.0 would mean that these tags are supposed to be ignored cause they are not a part of version 0.1.0.
Nianna
commented
9 months ago I would suggest:
Baklap4
commented
9 months ago Overall: a lot has been discussed in other issues. It might be hard to follow all of the activity, but i tried my best to summarize it here based on your statements/questions @Nianna
The spreadsheet is a nice idea but it would be nice if it contained all information and was a single point of truth. Now by looking just at it I feel like I'm missing half of the info that is probably spread over various issues here on github.
The spreadsheet will be long gone after things have finalized. The single point of truth will be this repository
Could you please add info why the tags were deemed deprecated and why others were renamed? For example I don't see why we would want to rename #MEDLEYENDBEAT to #MEDLEYEND? Is there any gain in that?
This has to do with an open issue #24 as noted the namechange will only happen after 1.0.0 in which these tags can get deprecated. Also everything currently in 1.1.0 or higher is only theoretical so please join these active tickets. It's not set in stone yet
Also, what are the new tags supposed to mean? e.g. #ONLINE ?
Also an open item as of yet #22
But why? Can't we treat version 0.2.0 (using excel numeration) as default version? None of the songs right now have #VERSION tag. But many of them do have tags like #GAP, #VIDEO, #COVER. Treating the files as files in version 0.1.0 would mean that these tags are supposed to be ignored cause they are not a part of version 0.1.0.
Purely to define the basics you need to get started. Yes i agree that many texts out there already contain a lot more, but if you'd just want to have a song to be singable in all of the apps these need to be defined. However we can automate things when certain tags are available to make it up to atleast 0.2.0 (as most songs probably would qualify). This will be a seperate process and is out of scope for this discussion.
treating the list of all tags that we collected just as a reference list - this is not a version. Let's not make this mess sth "standarized"
I agree that the collected list is a reference list. For the 1.0.0 we already scrapped some tags like #RELATIVE (all colored red within 0.3.0) If you think this list might need a more thorough cleaning please join the discussion that's why we're all here ;)
Defining version 1.0.0 - first offixial version - which should be the "cleaned up" version that is logically sound - contain no duplicated tags (e.g. leave only P1, remove #DUETSINGERP1; remove all deprecated tags, #MP3 tag may be renamed to #AUDIO, we may require support for multi-values in some tags (e.g. creator) and for different units in time related tags. The last to are up to discussion. This version should not have new features, just minimal changes to clean up what we have now into something that makes sense.
#AUDIO is a newly introduced tag which came from the discussions in discord / issues here. Personally i'd file this under 1.x.y since its new and not yet defined whereas #MP3 is fully defined.
Gonna link my previous comment on how i got to the versioning -> https://github.com/UltraStar-Deluxe/format/issues/13#issuecomment-1730926804
Finally - start working on version 1.1.0 which will have all new shiny features like #INSTRUMENTAL, #VOCALS, #ONLINE etc.
Every version after 1.0.0 can contain anything new and shiny. Agreed. This is already reflected within the spreadsheet.
We should give plenty of time for everyone to implement version 1.0.0 before releasing 1.1.0
I disagree. Sure the software should catch up eventually. But we won't be able to control what everyone on the web is doing. So there's no need for us stopping to invent stuff and come up with things.
All new version starting from 1.0.0 should be backwards compatible (unless there is a really really good reason to drop backwards compatibility, but in such case we should use new major version e.g. 2.0.0)
Since we're using semver this is already the case. Please read up on the linked comment of mine :) https://github.com/UltraStar-Deluxe/format/issues/13#issuecomment-1730926804
Create some standalone tool that will automatically convert all user's songs from no format to format 1.0.0 and between format versions.
Tools like usdb-syncer or creator software should always try to aim for the last version. This will make sure that eventually all the songs get pushed towards the latest. Like also already mentioned we could create statistics about version usage and eventually try to bump everything to the latest. But this will be a huge operation. IMHO we or an automation tool shouldn't alter users local songs. That's the job of the song-providers (usdb.animux.de / ultrastar-es / others) and creator software.
Karaoke programs will have to probably implement all the versions to be of best service. However if they want they can start from 1.0.0 and hopefully soonish we'll have everything ported to 1.0.0
rakuri255
commented
9 months ago Do we need E end of file? I mean it is clear to every software when end of file is. You don't need to define that extra.
marwin89
commented
9 months ago Baklap4
commented
9 months ago Do we need
Eend of file? I mean it is clear to every software when end of file is. You don't need to define that extra.
I'm not quite sure why E was a thing to begin with. Maybe someone can explain how it got into place?
As @rakuri255 mentioned for developers end-of-file is easy enough to detect. Maybe a usecase for non-developers we might miss?
Nianna
commented
9 months ago The spreadsheet will be long gone after things have finalized. The single point of truth will be this repository
I just meant to use it as a single point of truth while we work on the draft, with tags being linked to the related issues for reference. Just like @marwin89 did, thanks for that 👍
That's the job of the song-providers (usdb.animux.de / ultrastar-es / others) and creator software.
It's just not gonna happen. Also it will not update the songs that users have locally. Without any tool that we can tell the user to use, all formats will have to be supported like forever. But I never meant it to be a part of this project, so it's unrelated to this issue.
I still do not see the point of having v0.1.0. Same with v0.3.0 - new version just to deprecate some tags? Why can't we have just one version instead of these 3? We could define a list of required tags, a list of optional tags + info which tags are deprecated (and what should be used instead if applicable).
As you have said yourself- all tools will have to implement all versions. Why make the life harder for everyone and define 3 versions instead of 1?
Baklap4
commented
9 months ago I just meant to use it as a single point of truth while we work on the draft, with tags being linked to the related issues for reference. Just like @marwin89 did, thanks for that 👍
Yes very nice!
It's just not gonna happen. Also it will not update the songs that users have locally. Without any tool that we can tell the user to use, all formats will have to be supported like forever. But I never meant it to be a part of this project, so it's unrelated to this issue.
The tool to use at least for usdb could be maybe the USDB-syncer. There's an open issue on how to stay up to date which will need some more clarification (and thus getting users over to the latest versions).
I still do not see the point of having v0.1.0. Same with v0.3.0 - new version just to deprecate some tags? Why can't we have just one version instead of these 3?
Why do we want version 0.1.0 -> Karaoke software just starting out which want to play an ultrastar song can build their software with just these tags/notes and they'll have a working karaoke. This is the mvp (minimal viable product) and is often used to get a project started.
With 0.2.0 we (format project) want to specify tags that are already out there. This is mainly for compatibility with the already existing songs out there. Some songs qualify for 0.2.0 from the start, some won't.
Version 0.3.0 is used to clear up the mess we made over the past decade. It's nice for developers to deprecate things to give them a heads up of what's going to change and maybe a why it's going to change and what to use instead.
Then from version 1.0.0 this mess is cleared up (and thus we introduce a major bump since it'll break some karaoke programs).
I think the transition from 0.1.0 to 1.0.0 can be mostly automated and thus it wouldn't be needed to support all of these versions. It's mainly a reference point to show how this project evolved what led to version 1.0.0
As you have said yourself- all tools will have to implement all versions. Why make the life harder for everyone and define 3 versions instead of 1?
The different softwares out there can decide themselves what version they want to support. A strategy is mentioned in the sheet. With the help of #32 software can show what they support and what not.
We could define a list of required tags, a list of optional tags + info which tags are deprecated (and what should be used instead if applicable).
The required list of tags (for atleast version 1.0.0 - and everything before that -) are all the tags listed in v0.1.0. All other tags are optional.
marwin89
commented
9 months ago FYI: OVERVIEW Spreadsheet updated (semver strategy vs anual strategy)
marwin89
commented
9 months ago Pre-Condition for this issue: we need to agree on version strategy #13 first to continue this issue. There is a voting till 14th oct 2023.
achimmihca
commented
8 months ago With 0.2.0 we (format project) want to specify tags that are already out there.
I think this is beneficial for communication with users. You can just point them to the spec and from there they can find how the format changed and thus how to update their songs.
marwin89
commented
7 months ago Thanks for discussing version structure. We voted for this in issue:
Here are the final results.
Our versions will start with this structure 0.1.0 -> Bare Minimum, Minimum vial product (mvp) 0.2.0 -> Introduce the tags we currently have 0.3.0 -> Deprecate old # tags we don't wanna use (duplicates, technical not nessecary) 1.0.0 -> Removal of deprecated tags and final list of currently used tags (2023) 1.1.0 -> First new features we want to introduce, deprecated #mp3 and chaotic time units (2023) ~1.2.0 -> more new features (2024) 2.0.0 -> Removal of #MP3 and introduce unified time units (=doing breaking changes) (2025)
Suggestion
According to #13 strategy:
Use case
Start versioning. Having a version we can build up upon and categorize txt-file entries in hostings.
Extra info/examples/attachments