Make linebreak timings optional?

[bohning]

Suggestion

The linebreak timing seems to be mandatory at the moment (at least in USDX), but it could be made optional, thus letting the application handle the (ideal moment of) transition between lyric lines. Melody Mania an Performous seem to consider linebreak timings optional, while they are currently mandatory for USDX (will not load the file), YASS (will corrupt the file upon save, preprending # to all linebreaks) and UltraStar Manager (will corrupt the file upon save, deleting all linebreaks).

Use case

If the linebreak timing is optional, the application could handle the transition, and may or may not respect explicitly stated timings. This would simplify the file format.

Extra info/examples/attachments

No response

[Baklap4]

Will try later tonight in performous. As i'm not sure if the timing element is needed.

So basicly you'll want this to be the norm in the txt format:

: 52 15 2 lyrics
-
: 68 2 -2 other lyrics

Instead of the currently mandatory linebreak timing:

: 52 15 2 lyrics
- 68
: 68 2 -2 other lyrics

[bohning]

I tried in Performous, the file is loaded and plays just fine without linebreak timings. So obviously Performous does the calculation itself already (so the question is: does it ignore the set timings and always use the internal calculation, or does it respect the explicitly state linebreak timing if it is present, but calculates it when it is missing?).

We could debate what the default/norm should then be, or we could discuss of how to handle both cases (as currently the vast majority of txt files contain linebreak timings).

The software should be able to handle files both with and without linebreak timings. It may (or should, or must) respect explicitly stated linebreak timings (allow customization), or this could be a setting (e.g. "always recalculate linebreak timing" vs. "always use linebreak timings of the txt file if present").

[Baklap4]

https://github.com/performous/performous/blob/master/game/songparser-txt.cc#L188C1-L198C4

This is what performous does under the hood,
So it either reads the time and shifts the lyrics (relative mode) or when not available goes to the next note.
consecutive sleeps are ignored

I think it'd be wise to discuss how to handle both cases as both cases are around (your option of a setting might be good, but also might be unnecessary if the fallback is to always calculate it). I do like the explicitness as we also do with the E note-type. But i agree that the program can/should be able to handle both cases as this makes for a smoother experience for the end-user.

[bohning]

See for example: https://usdb.animux.de/index.php?link=detail&id=29342

[basisbit]

there are plenty of songs out there which rely on the linebreak timing to "hide" the upcoming line until the last moment for various reasons. Please don't break this, instead I suggest supporting both cases.

[Baklap4]

there are plenty of songs out there which rely on the linebreak timing to "hide" the upcoming line until the last moment for various reasons. Please don't break this, instead I suggest supporting both cases.

Yes that was a behavior i'm still wanting to test within performous.
Within performous we also have an option that says "Press enter to skip instrumental break". I think that also relies on this.

[achimmihca]

there are plenty of songs out there which rely on the linebreak timing to "hide" the upcoming line until the last moment for various reasons.

And I think this is a valid use case.

However, I also think that it should not be mandatory to add these linebreak timings.
When not present, then it is responsibility of the game to find the best suited linebreak timing.
Might make life easier for song creators.

[codello]

I do understand the idea of optional line break timings and I'm not against it. This kind of syntax change would be something for v2 I think?

However this change introduces the requirement for notes to occur in order in the file (at least per phrase) which is currently not required (technically it's still undecided). This would introduce new edge cases like:

: 5 3 0 hello
-
: 10 5 0 small
-
: 7 1 0 world

What is the expected way to handle a case like this?

[Baklap4]

@codello i just tested this scenario within performous and in this case it prints:

hello
small

skipping the world marking it as 'overlapping' with : 5 3 0 hello

If i change the txt slightly to not overlap it still filters out the world 'cause of overlapping.. which isnt correct

karaoke software can order the txt content based on the beat.. which would solve this edge case. For now, most if not all software read the txt file as is, line by line

[codello]

karaoke software can order the txt content based on the beat.. which would solve this edge case.

I'm not sure I see how this is resolved. The notes can easily be ordered by start beat, giving

: 5 3 0 hello
: 7 1 0 world
: 10 5 0 small

But where are the two line breaks supposed to be? After hello and small? Before small and world? Without times for the line breaks this feels pretty ambiguous to me.

For now, most if not all software read the txt file as is, line by line

This is an important point. I haven't looked at the different implementations but if the general consensus is that notes in a song need to appear in ascending order in the file anyway then we could just make that a requirement in the spec. I wouldn't be opposed to that. And then optional line break timings make sense to me (for v2 of the file format).

I also don't think the requirement of ordered notes would cause problems in practice since all songs I know of are ordered already.

[Baklap4]

But where are the two line breaks supposed to be? After hello and small? Before small and world? Without the line breaks this feels pretty ambiguous to me too

The order comment was about lines being out of order (irrelevant to this issue). This shouldn't cause an issue except that it currently does within performous. Not sure how other software is handling that case

out of order:

: 5 3 0 hello
-
: 10 5 0 small
-
: 7 1 0 world

in order:

: 5 3 0 hello
-
: 7 1 0 world
-
: 10 5 0 small

[codello]

I have given this some thought. The requirement of notes occurring in order of start time and the possibility of optional line break times are for me basically a combined decision: If notes do not have to be ordered I think optional line break times introduce a level of ambiguity into the format that isn't worth the convenience. If notes have to be ordered then line break timings can as well be optional.

I have a slight preference towards requiring that notes occur in order and to allow optional line break timings - mostly because I wouldn't really want an implementation to generate songs where notes are not ordered.

[bohning]

Is there a use case for not having them in order? I would assume not and that out of order notes are always unintentional errors by song creators/tools that should not happen. So I'd vote in favor of having notes in order, making linebreak timings optional.

[codello]

I can't think for a reason. The spec mainly marks this as undecided. I originally wrote it that way because until now there wasn't a reason to force order. At least in absolute mode the explicit start times of notes were unambiguous.

Another argument for the order requirement (and maybe for optional line break times) is that it is consistent with player changes (P1, P2, …). For those the order in which notes appear in the file is already significant.