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 of a reason. The spec 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.

[basisbit]

One of the reasons for why the txt file format was so successful for so long was because it is very sturdy and especially easy to edit manually by people with very little knowledge about the details. Making the format so much stricter that just copy+pasting sentences will result in problems (because the above mention order requirement) imho only brings downsides and has no upsides.

[codello]

Could you give me an example where this copy+pasting would be useful? I currently don't really see a use case where you would copy+past some notes without also wanting to adjust the start times.

[marwin89]

SUMMARY / VOTE NOW 📈

Dear all,

thanks for the discussion about optional linebreak timings and forced order of notes. We are close to a final result. Please vote for your favorite option till 21th feb 2025 with emoticon ❤ 🚀 🎉 here now.

❤ Option 1:
Notes MUST be in order + linebreak timings CAN be optional (game implementation have to calculate them by themselfs)
Introduce in spec Version 2.0.0

🚀 Option 2:
Notes MUST be in order + linebreak timings MUST be defined

🎉 Option 3:
Notes CAN be in order + linebreak timings MUST be defined

@bohning this is a well written suggestion, thanks for your effort. If this issue is approved you can make a PR (with the help from @Baklap4 and @codello). I assign it to you.

[achimmihca]

I am fine with the above voting options.

But still want to share my thoughts here.

---

Personally, I think this is a matter of definition (and we are free to define it).

For me, it feels natural to define it as

• the separator is after the previous note ("it belongs to the previous note" one might say)

Consider the example from above

out of order:

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

I would read this example as "a separator after hello and a separator after small". Thus, the phrases would be (with notes ordered by beat) hello, world small.

This defintion allows some freedom.

• Implementations are free to choose the exact separator location as long as they keep the order of phrases intact

To me, this definition is rather intuitive because it already looks like a "cut" between words.

One of the reasons for why the txt file format was so successful for so long was because it is very sturdy and especially easy to edit manually by people with very little knowledge about the details

I agree. And I see optional linebreak timings in line with this because it makes it easier to shift linebreaks around in the file, without the need to adjust any numbers.

For example, above outcome might not be intended by the song creator.
Let's assume the order of the words should be hello small world. Then to fix the song, one only needs to shift world up, but does not need to adjust any numbers.

Notes MUST be in order + linebreak timings CAN be optional (game implementation have to calculate them by themselfs)

As shown in the example above, I think my definition how to interpret it would also work with Notes CAN be in order + linebreak timings CAN be optional.
But of course it would also work with the more strict voting option above, so I am fine with this.

I think out of order notes can always be considered a mistake by the song creator. But we are free to make something out of it (hopefully something intuitive).

"What happens if there is no previous note" you might ask. Well, I would argue "same as with linebreak timings", i.e., ignore the separator if there is nothing to separate.

[codello]

Thanks for the extensive explanation @achimmihca.

For me, it feels natural to define it as the separator is after the previous note ("it belongs to the previous note" one might say)

I do see your point and agree that optional line breaks could be defined in a way that ist resolvable (by definition, basically). But I haven't yet seen a convincing argument to do so, so I don't think it's worth the effort.

I think out of order notes can always be considered a mistake by the song creator. But we are free to make something out of it (hopefully something intuitive).

I agree! If an implementation really wants to support optional line breaks with out-of-order notes they still can. I would prefer if such a behavior remains unspecified and is up to the implementation. I wouldn't want to see a song editor producing files make use of this "feature".

To me, this definition is rather intuitive because it already looks like a "cut" between words.

I think this depends on the example. I think the following doesn't look as intuitive anymore:

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

To me this visually looks like the intention is to not have a phrase break between hello and small. If phrase breaks follow either their preceding or succeeding note this wouldn't be the case anymore.

This is of course something that can be resolved by definition. But I don't think it's worth the hassle and it's easier to just enforce a strict note order so that these ambiguities don't even come up.