Multi-track drifting is back. WITH A VENGEANCE.
So, we talked with @red5h4d0w @Dragicafit and @aeden-b about this on a sunny saturday afternoon and we decided we wanted to revive this. The old issue #323 (closed) isn't reopened because it was too broad. We were trying to do something too generic.
This particular issue will focus on LYRICS first. We'll work on AUDIO tracks later.
The Why.
Why revive this now ? There are multiple reasons.
- **Kana versions of songs are basically the same language/media but with a different ASS file. This doubles space used by songs, and clutters the song list.
- We could possibly (re-)add all Bakaclub versions of the ASS files when importing them, so people could choose if they want fancy effects or not.
- Other alternative versions could work, like
- Without chorus versions
- With sound effects versions (because why not?)
- etc.
The How.
For maintainers
Karaoke import form needs a way to add several lyrics files and define :
- Their type : Romanji/Kana/Chinese/Romanji with effects/etc.
- Their priority : Which should be the default ?
ASS types will be tags in a new tag type (which will allow everyone to filter songs according to what they want to see)
Other ideas?
For operators
- When listing songs from a playlist, we need a way to tell which ASS has been loaded for that playlist element
- ASS file can be changed in the karadetail modal (when clicking on a song in the playlist)
- Optional : a way to change the current song ASS on the fly ?
- When adding a song from the library, open a modal allowing the operator to select which ASS they want if more than one is present
- When adding several songs, pick the default ASS.
- Preselect the default one.
-
Radio buttons and a OK button should do the job.Radio button will need two clicks to add a song. I think buttons with the ASS types as labels will be better
For users
- The karaline should include which ASS is selected when it's a playlist item
- Should the karaline for the library list ASS types, or the number of ASS types available ?
- The new tag type should be browsable for those who want to see how many songs have Kana writing.
-
Should we offer preferences for the user to make specific ASS types their default ?
- I'm not too sure about that since users are repository-independant.
- When selecting a song/version, a modal should open to ask which lyrics version they want if there is more than one, with the default preselected. See above.
The How (for developers.)
JSON format
The JSON schema we use for kara.json already considered the idea of multiple subfiles.
"lyrics": [
{
"filename": "JPN - Mahoromatic Automatic Maiden - OP - Kaerimichi.ass",
"default": true,
"version": "Default",
"subchecksum": "42340c44b558b3059833d5e342113d08",
"authors": [
"tid1", // Kmeuh
"tid2" // Someone else
],
"tags": [
"tid1", // Romaji
"tid2", // With Special FX,
"tid3" // With Chorus
}
]
As we can see the lyrics
element already is an array.
-
version
should be kept as a string to keep this compatible with older KM versions. -
filename
will append theversion
to its name, like thisJPN - Mahoromatic Automatic Maiden - OP - Kaermichi (Default).ass
- A
versiontag
property will be added with the relevant TID for the version. -
Should TIDs of all
versiontag
s be listed in thetags
field for the song?- This will help with database integration to link lyrics types with karas, but I fear we might have to add some code to hide it from view for some things like import form or karadetail modal. To avoid adding custom code we could prefix the tagtype with
internal_
and add code that filters them out whenever we need to list tagtypes of a song. For exampleinternal_lyrictypes
but I'm not sure if this is a good idea or not. - When importing, KM can also add these tags automatically to the kara, but they will still be in detabase at the same place the others are.
- This will help with database integration to link lyrics types with karas, but I fear we might have to add some code to hide it from view for some things like import form or karadetail modal. To avoid adding custom code we could prefix the tagtype with
In database
We'll need a new subfiles
field. Storing it as a JSON object seems good to me since we don't need to query through it but just store and return it for each song.
In code
It's a bit too early to identify everything that will need changes. Modifying the kara
type will allow us to have a clearer view of impacted code.
Conclusion
If you have any comments on this, feel free to comment below! :)