f2e-spec
f2e-spec copied to clipboard
alibaba
Support more than 2 vocal tracks (txt)
Actual behaviour
I'm having a txt file with 4 players defined. And performous shows only 2 lines of text (as it'd have been a duet mode):
Expected behaviour
I thought it'd have shown me 4 lines of text since i've defined 4 players in my txt file.
this is the txt file i'm using:
#ARTIST:Andrew Lloyd Webber Ft. Tim Rice
#TITLE:I Don't Know How To Love Him
#MP3:ANDREW LLOYD WEBBER AND TIM RICE - i dont know how to love him.mp3
#AUTHOR:Asgard Sings!
#EDITION:Jesus Christ Superstar
#LANGUAGE:English
#BPM:288.84
#GAP:4560
#BACKGROUND:background.jpg
#COVER:cover.jpg
P1:
: 0 21 18 I
: 28 6 19 don't
: 36 6 18 know
: 44 6 16 how
: 52 5 14 to
: 60 22 23 lo
: 83 6 21 ~ve
: 91 29 21 him,
- 120
: 139 6 19 What
: 147 3 18 to
: 152 5 16 do,
: 171 6 18 how
: 178 3 19 to
: 183 26 18 mo
: 210 6 16 ~ve
: 218 13 16 him.
- 231
: 236 13 13 I've
: 250 5 11 been
: 257 27 9 changed,
: 289 6 18 yes,
: 297 7 18 rea
: 305 6 16 lly
: 314 39 9 changed.
- 353
: 365 3 18 In
: 369 4 19 these
* 376 19 21 past
: 400 6 21 fe
: 407 4 14 ~w
: 413 14 14 days,
: 429 4 16 when
: 434 6 14 I've
: 449 11 21 seen
: 462 6 21 my
: 471 17 14 self,
- 488
: 495 5 18 I
: 502 15 19 seem
: 519 13 18 like
: 534 8 16 so
: 543 4 14 ~me
: 549 8 14 o
: 558 7 16 ~ne
: 567 48 16 else.
- 615
: 632 24 18 I
: 661 6 19 don't
: 669 6 18 know
: 677 6 16 how
: 684 4 14 to
: 693 23 23 ta
: 717 6 21 ~ke
: 725 31 21 this.
- 756
: 772 6 19 I
: 780 5 18 don't
: 788 8 16 see
: 800 10 18 why
: 811 6 19 he
: 819 24 18 mo
P2:
: 0 21 18 I
: 28 6 19 don't
: 36 6 18 know
: 44 6 16 how
: 52 5 14 to
: 60 22 23 lo
: 83 6 21 ~ve
: 91 29 21 him,
- 120
: 139 6 19 What
: 147 3 18 to
: 152 5 16 do,
: 171 6 18 how
: 178 3 19 to
: 183 26 18 mo
: 210 6 16 ~ve
: 218 13 16 him.
- 231
: 236 13 13 I've
: 250 5 11 been
: 257 27 9 changed,
: 289 6 18 yes,
: 297 7 18 rea
: 305 6 16 lly
: 314 39 9 changed.
- 353
: 365 3 18 In
: 369 4 19 these
* 376 19 21 past
: 400 6 21 fe
: 407 4 14 ~w
: 413 14 14 days,
: 429 4 16 when
: 434 6 14 I've
: 449 11 21 seen
: 462 6 21 my
: 471 17 14 self,
- 488
: 495 5 18 I
: 502 15 19 seem
: 519 13 18 like
: 534 8 16 so
: 543 4 14 ~me
: 549 8 14 o
: 558 7 16 ~ne
: 567 48 16 else.
- 615
: 632 24 18 I
: 661 6 19 don't
: 669 6 18 know
: 677 6 16 how
: 684 4 14 to
: 693 23 23 ta
: 717 6 21 ~ke
: 725 31 21 this.
- 756
: 772 6 19 I
: 780 5 18 don't
: 788 8 16 see
: 800 10 18 why
: 811 6 19 he
: 819 24 18 mo
P4:
: 0 21 18 I
: 28 6 19 don't
: 36 6 18 know
: 44 6 16 how
: 52 5 14 to
: 60 22 23 lo
: 83 6 21 ~ve
: 91 29 21 him,
- 120
: 139 6 19 What
: 147 3 18 to
: 152 5 16 do,
: 171 6 18 how
: 178 3 19 to
: 183 26 18 mo
: 210 6 16 ~ve
: 218 13 16 him.
- 231
: 236 13 13 I've
: 250 5 11 been
: 257 27 9 changed,
: 289 6 18 yes,
: 297 7 18 rea
: 305 6 16 lly
: 314 39 9 changed.
- 353
: 365 3 18 In
: 369 4 19 these
* 376 19 21 past
: 400 6 21 fe
: 407 4 14 ~w
: 413 14 14 days,
: 429 4 16 when
: 434 6 14 I've
: 449 11 21 seen
: 462 6 21 my
: 471 17 14 self,
- 488
: 495 5 18 I
: 502 15 19 seem
: 519 13 18 like
: 534 8 16 so
: 543 4 14 ~me
: 549 8 14 o
: 558 7 16 ~ne
: 567 48 16 else.
- 615
: 632 24 18 I
: 661 6 19 don't
: 669 6 18 know
: 677 6 16 how
: 684 4 14 to
: 693 23 23 ta
: 717 6 21 ~ke
: 725 31 21 this.
- 756
: 772 6 19 I
: 780 5 18 don't
: 788 8 16 see
: 800 10 18 why
: 811 6 19 he
: 819 24 18 mo
P5:
: 0 21 18 I
: 28 6 19 don't
: 36 6 18 know
: 44 6 16 how
: 52 5 14 to
: 60 22 23 lo
: 83 6 21 ~ve
: 91 29 21 him,
- 120
: 139 6 19 What
: 147 3 18 to
: 152 5 16 do,
: 171 6 18 how
: 178 3 19 to
: 183 26 18 mo
: 210 6 16 ~ve
: 218 13 16 him.
- 231
: 236 13 13 I've
: 250 5 11 been
: 257 27 9 changed,
: 289 6 18 yes,
: 297 7 18 rea
: 305 6 16 lly
: 314 39 9 changed.
- 353
: 365 3 18 In
: 369 4 19 these
* 376 19 21 past
: 400 6 21 fe
: 407 4 14 ~w
: 413 14 14 days,
: 429 4 16 when
: 434 6 14 I've
: 449 11 21 seen
: 462 6 21 my
: 471 17 14 self,
- 488
: 495 5 18 I
: 502 15 19 seem
: 519 13 18 like
: 534 8 16 so
: 543 4 14 ~me
: 549 8 14 o
: 558 7 16 ~ne
: 567 48 16 else.
- 615
: 632 24 18 I
: 661 6 19 don't
: 669 6 18 know
: 677 6 16 how
: 684 4 14 to
: 693 23 23 ta
: 717 6 21 ~ke
: 725 31 21 this.
- 756
: 772 6 19 I
: 780 5 18 don't
: 788 8 16 see
: 800 10 18 why
: 811 6 19 he
: 819 24 18 mo
E
Steps to reproduce
Grab this txt file and try playing the latest performous.
Be aware that P3 means "both" in the UltraStar file format. I would also suggest to coordinate with the USDX people, for example @basisbit, on how to extend the file format.
Hmm beside the P3 = both thing we'll also face issues regarding UI.. since the screens are too small to show 4 lines of text below eachother most of the times
honestly, I suggest to not implement having more then two players lyrics (plus notes + scores for each player) shown at the same time at the screen. Performous is already quite crowded with features and we should try to simplify the user interface instead of adding even more to the singing screen. Two voices duet works somewhat ok because you can tell the people that the ones with the blue ring around the singstar microphones (or similar) sing the lyrics in the top of the screen and the ones with red microphones sing the notes at the bottom of the screen (or wherever the lyrics are displayed).
I checked my Soramimi database and if I checked correctly, I didn't see any songs with more than 3 different singers singing simultaneously. Would it be possible to put 1 line at the very top, 1 line in the middle and 1 at the bottom? So P1 = singer 1, P2 = singer 2, P3 = together, P4 = singer 3 at the top of the screen (not used very often) ?
Example Soramimi lyrics
-
Lion King_Arm land [musical].txt Youtube link: https://youtu.be/cA3s54bQhEk
-
Lion King_Wij zijn een.txt Youtube link: https://youtu.be/woX7PLvKzFk
soramimi uses color codes and alternates between 2 lines, so you could do 4 vocal tracks at once as long as those 4 players don't sing at the same time, otherwise it produced very weird flickering glitches. (but soramimi is now over 10 years old anyways and unmaintained so adding it in performous would be better)
@basisbit if you enable karaoke mode there's plenty of space left, otherwise you could make the text smaller and squash the notegraph, or split the screen sideways ala mariokart. Performous already has defines for layouts like this in layoutsinger.hh:
enum PositionMode {FULL, TOP, BOTTOM, LEFT, RIGHT};
although LEFT and RIGHT were never implemented/used but it's good to see that it was kept in mind during initial implementation.
I'd still go for a suggestion mentioned in discord: Use multiple screening when available. So we'd still have 2 lines of text at one screen. If there are no more than 1 screen available show a max of 3 lines of text at one screen (for at least the karaoke mode since this won't get too crowded). I'd go the following format: P1 = player 1, P2 = player 2, P3 = ALL, PX for all subsequent number of players.
This would need a few changes and i think it'd be the best to keep it dynamic and support as much microphones/lines of text as you want
Besides this we'd need to update composer to actually support duet modes see: https://github.com/performous/composer/issues/30
@selenebroers I’d love to put some SATB pieces into Performous, which would need four players at least.
suggestion for changes to the ultrastar file format parsing:
- if a file contains no P1 or P2 in the notes part, it is a single-voice song. Nothing to do.
- if the song contains P0, then P0 marks sentences for all voices, while P1 .. Pn mark sentences for the respective voices.
- if the song contains only P1 and P2, use these for the players, alternating between the voices when there are more than two voices.
- if the song contains P1 and P2 and P3 but not P0 and not P4, use P1 and P2 for the players, alternating between the voices when there are more than two voices, and use P3 for sentences that are for all voices to be sung.
- (all "else" cases) if the song contains P1 and P4, but not P0, then P1 .. Pn mark sentences for the respective voices
This would support legacy files, while also supporting more than two voices. Only downside would be that it is a bit complicated and does not support the case no shared sentences and exactly 3 voices.
This would be very easy to understand for new songs being created: P0 for all (mandatory, empty line allowed if no shared sentences), P1 .. Pn for the voices.
Some suggestions to have a broader discussion:
-
I suggest to use
PXinsteadP0to indicate all voices. I am used to start counting from 0 (e.g. in for-loops).PXbreaks with the pattern P[number] to make it more clear that it is not a single voice. The X is a placeholder for "any number". -
"all voices" is a special case of "multiple voices". Thus, we could instead only define a syntax to provide notes for "multiple voices", for example, a comma separated list. Example:
P1
: 0 0 0 lalala
P2
: 0 0 0 lalala
P3
: 0 0 0 lalala
P2,P3
: 0 0 0 lalala
P1,P2,P3
: 0 0 0 lalala
P1,P3
: 0 0 0 lalala
-
We could just not support special syntax for multiple or all voices. This feature does not extend what can be expressed in a song. You can argue that it can reduce file size and make it easier for people who edit txt files manually. However, I argue that the smaller file size is negligible. Furthermore, writing complex UltraStar song files should be done with a dedicated song editor such that there is no need to edit the txt files manually.
-
alternating between the voices should always be allowed (no matter how many voices are given in the song). For example, one could write the voices in the following sequence: P1,P4,P1,P2,P1,P3.
-
We are discussing changes to the file format. So we are basically introducing a new version of the file format. Your suggestion is to decide which version is used, based on the occurences of voices in the song. This has the disadvantage that you have to read all voices first before you decide what to make with them. Instead I suggest to introduce a new version tag to the file (e.g. #TXTVERSION:2). If this tag is found, then the new parsing rules are applied. Otherwise, the old parsing rules are applied.
- This approach would also make it possible to introduce new versions in the future.
- As alternative to the version tag, one could also introduce S[number] instead of P[number] for the new version. For example, you could have S0...Sn indicate the voices of singer 0 to singer n (no special stuff for "all voices" or "multiple voices". Of course S[number] and P[number] cannot be mixed in the same file.
Question:
What happens when some voice indexes are missing? Is such a song file allowed, or do we reject it? Example:
P1
: 0 0 0 lalala
P2
: 0 0 0 lalala
P5
: 0 0 0 lalala
P2
: 0 0 0 lalala
P8812721
: 0 0 0 lalala
From the above suggestions, my vote goes to:
- version tag for the new format.
- P0...P[number] are allowed, but not alternating. Thus, P0 must start and P[n] can only be followed by P[n+1]. P[n] indicates the voice of the singer n.
- I would not provide special syntax for "multiple voices" or "all voices". A smart editor can generate a dumb yet simple file format.
Should probably ditch the UltraStar TXT format already and use MID/INI format (FoF) instead.
the ultrastar txt format is so successful, because it is simple and easy to understand + modify even without reading docs. Ditching the txt format for sing-along karaoke mode would be equals to ditching 99% of the community and ending up with next to no users and almost no content. USDX and US Play will not do that. Doing the changes which @achimmihca suggest would not break usage of the song files in other games and should work well, as we together can update Performous, Yass, UltraStar Creator, UltraStar Manager, USDX and UltraStar Play for that and thus not be annoying or any problem for the users ("customers"). 😛
By the way, we are planning on slowly dropping support for non-default codepage encoded special characters in Ansi txt files. UltraStar manager already converts all non-UTF-8 files to UTF-8 for users.
L. Kärkkäinen dixit:
Should probably ditch the UltraStar TXT format already and use MID/INI format (FoF) instead.
I’ve tried using MIDI (as exported from MuseScore (notation program) or AnthemScore (like Performous Composer)), but was very unsuccessful.
In the end, I used midicsv from the midicsv Debian package to convert the MIDI to CSV, then some simple text transformations and integer divisions to convert that to a TXT file (with BPM 3600) and added back the lyrics.
So far, the TXT format, with all its limitations, has been the only one discoverable and hackable enough to do the job of creating some‐ thing for Performous at all; Composer was some very limited aid in postprocessing the start/end times in that text file, and the other editors I tried were not very helpful, either.
So I’d argue in favour of keeping it.
I don't personally see the value in more than two voices but if it can be implemented then sure I guess.
I like the idea of using a version tag and definitely think we should keep TXT.
By the way, we are planning on slowly dropping support for non-default codepage encoded special characters in Ansi txt files. UltraStar manager already converts all non-UTF-8 files to UTF-8 for users.
Why though? I mean yeah it's a hassle but I made sure already we have a functional conversion to unicode. I wouldn't waste much effort on anything related to non-ansi non-unicode support but I don't see any need to remove existing functionality if it doesn't impact the code negatively in any way.
Sorry, I wasn't clear on this. We are only dropping the support in USDX and US Play, because the different codepages for Ansi cause problems for users and trying to autodetect codepages is slow. We drop official support, not the code which already exists.
Gregorio Litenstein dixit:
I don't personally see the value in more than two voices but if it can be implemented then sure I guess.
I’d like to convert lots of SATB choir pieces and use Performous as training tool, where up to eight people would then be able to select their track and train it, at the same time.
That’s one of my use cases (and the reason I’d love to be able to show musical notation instead of semitone-distance lines).