More than 2 vocal tracks

[achimmihca]

Suggestion

I want to forward a discussion from performous about more than 2 vocal tracks.

Is this actually needed in the first place? What do you think?

Use case

Sing a song with more than two singers, e.g., a canon.

Extra info/examples/attachments

No response

[Baklap4]

Heheh nice! Yes it'd be nice to make this possible 🎉 however it comes with some complexity + it's a small selection of songs which have this.

If we're gonna try to tackle this it should be an extension/enhancement of the format as we cannot fit this in the current format

The usecase would be if there are more than 2 singers singing at the same time different lyrics: canon songs

Another usecase (but already fits in the current format) is to alternate between singers when no one is singing. For example the song Binetsu kara mystery: 3 singers alternating voices which currently fit since no lyrics are overlapping

[basisbit]

use P0 or PX for all players, P1 for first track, P2 for second track, ... Pn for n-th track. Detect that this is used by checking if P0 and/or P4 is used somewhere within the sentences.

(No format change needed, just my 2 ct)

[basisbit]

actually, looking at that linked issue in the initial post here, many points were already mentioned / offered in that other issue. This would need quite some bigger changes in UltraStar Deluxe at least, probably not so much work in Performous because it has a much nicer codebase. Maybe @barbeque-squared could give some suggestions regarding how to get multi-track to work in USDX or at least have such songs which are made for performous not completely break when played in USDX.

[barbeque-squared]

_Personally, I would drop the idea of an "All" track altogether and just use P1/P2/P3/etc. Yes that means duplicating the lines sung be all voices. Also no trying to be smart and handle a P3 without a #P3/#DUETSINGERP3 as if it were secretly an "All" track.

My reasoning/questions are the following:

• It would make the format self-explanatory
• Are there currently any editors out there that actually support (read: save back) the "All" track?
• What kind of percentage is songs would legitimately benefit from having an "All" track?

I think especially that third point is quite relevant, because let's assume:	number of vocal tracks	percentage of all txt's
1	90%
2	9%
3	0.9%
4	0.09%
5 or more	well you get the idea

And I'm pretty sure those are very generous/biased towards multi-track txt's. I don't think the duplication caused by not having "All" really matters all that much for tracks with just 2 vocal tracks. I admit it might become more relevant the more vocal tracks a txt has (more so for songs with a chorus, less so for canons) but is it really worth having a P0/PX for the <1% that uses it for maybe just a few lines? Is not having to copy/duplicate those few lines really worth having non-self-explanatory implementations in every software? Same goes for the P1,P3,P4 I saw in the other issue.

"Editor hell" isn't really a valid reason not to do something, but: P1/P2/P3/P4/etc is the common divider among all solutions. I'm pretty sure this is the bit we all agree on, and it's also the bit which would make any number of vocal tracks Just Work. Anything else are just nice-to-haves which we could always add later in a way that doesn't even break the format, but I just don't see the point in supporting them right from the start. Especially USDX has already way too many features for "the less than 1%".

@basisbit wrt changes in USDX: I've been advocating to delete the current P3 hack for a while, but every time I mention it, there will be like 1 person getting anxious that it might impact like 0.02% of their songs. If we can get rid of that, it shouldn't be that hard to read+save back the extra tracks. Getting USDX to actually do something with more than 2 tracks, yes that will require significant changes, but they can be done incrementally. A lot of it is blocked by pending refactorings anyway.

[bohning]

The "current P3" hack refers to P3=P1+P2 combined with intertwined duets? I am all in favor of removing that from USDX.

I don’t see the advantage of a P0/PX "shared" track and would also favor the P1...Pn approach for n tracks. That’s easy to understand, easier to implement. However, I would wish for two things:

1. editor support to "lock" certain lines for certain players, so that a change in one is reflected in the other(s) (e.g. chorus sung by all tracks - if I need to edit it, I only need to edit it in one of the tracks and the change is reflected in the other tracks if they are in a "locked/connected" state)
2. A solution for duets alongside non-duet versions (should not displayed twice in the song selection, but rather have a popup when selected that asks if you want to sing the non-duet or the duet-version). This needs discussion if that only works if they share resources/reside in the same folder (two txts using the same audio/video/cover) or if that works also if they are in separate folders (one for the non-duet version, one for the duet-version) and if so, if that only works if the audio/video/cover resource are identical) - or if the non-duet and the duet-versions should be merged into one file (which makes it harder to handle/edit) - e.g. P0 for non-duet version, then P1/P2 for individual duet tracks.

[marwin89]

I'm definitly not a dev just a simple user. but I would drop the idea completely, Like bbq² and basisbit said. It's 1%. In IT-Management many people would say it's a thankless task - big effort low impact. As basisbit emphasizes keeping it simple is key (I would hold on to ITIL Guiding principiles "Keep it simple and practical").

[achimmihca]

I agree, the required work is probably not worth it.

Furthermore, this leads to new UI questions, e.g., where should the lyrics be displayed. With two vocals, one can place a lyrics box at the top and one at the bottom. This is done at the moment. But with 3, 4, 5 vocals?

I suggest to close this issue as "Won't fix".

---

That said, "P3" as shortcut for "P1 and P2" is still unintuitive and probably worth to get rid of. I don't think any such shortcut is needed actually. Instead, I suggest to create a smart editor that outputs a simple format.

[Baklap4]

Personally i'd love to see this. Back in lrc days we would distinguish with color coded sentences, with aegisub you get a new style for every new vocal, with ultrastar format it's not possible as of yet. I agree this is the 1% folks who need it, but having it (at least spec'ed) someday would be really nice. This will lead to discussion on how to view these sentences and such but if its within spec they can actually discuss about it

[codello]

I agree with @Baklap4 on this. I think it would be a missed opportunity for the spec to restrict the number of players. Even if the spec includes more than 2 players/voices per song games/programs don't necessarily have to support an arbitrary amount of voices. The spec could just leave this decision up to the implementation.

[achimmihca]

we would distinguish with color coded sentences

Indeed, this would be an option to show the lyrics in the UI. I found that this is also done by KaraFun, probably also by other karaoke software.

An alternative could be to show the lyrics underneath the player notes, like in Rockband.

games/programs don't necessarily have to support an arbitrary amount of voices

I agree. But the opposite is also true: the game/program is free to implement support for more vocals.

The question is: When is a game/program adhering to the spec? Supporting 2 vocals should probably suffice.

The spec now leaves room to have more vocals. Biggest obstacle for this was the "P3 means P1 and P2" hack, which thankfully was removed.

Defining the spec as "Pn is the start for the notes of player n, where n > 0" feels natural to me. But games/programs are free to implement this already.

In conclusion, I am fine with how the spec is now.

[codello]

Defining the spec as "Pn is the start for the notes of player n, where n > 0" feels natural to me. But games/programs are free to implement this already.

I absolutely agree, that‘s basically what I meant (but I worded that badly). My understanding was that the current state of the spec only allows n=1 and n=2. But maybe I misunderstood that. If your quote is indeed the current state of the spec then I‘m more than fine with that :)