Ignore "parenthesized expressions" that precede lyric syllables

https://github.com/musescore/MuseScore/pull/1391

Fixed as part of a PR whose main purpose is alignment of a lyric syllable with a leading verse number. See #36366: Parse verse number out of lyric and align lyric properly.

The thing is, the original title of this issue - and the other discussion you say it came from - is at odds with your actual example. I've updated the title to better reflect what I think you are actually asking for.

The new algorithm *does* ignore punctation, just as was originally requested. It just doesn't also parse the characters *after* the leading punctuation looking for something that could poentially be considered a match for some charcater in the leading string, and then also ignore all intervening characters as well. That's a completely separate thing, and rather harder to implement in the general case.

Realistically, reading the arranger's mind and figuring out exactly how he wants things aligned is just not going to happen. Right now, we ignore leading punctuation, just as the original discussion suggested. There is no doubt room for improvement if someone can describe accurately a precise algorithm - preferably implementable as a simple regular expression - for identifying what should be ignored and what should not. But whatever anyone comes up with, I guarantee it will be what is desired in some cases but not in others. Which is why I would caution against trying to get too clever. Knowing that leading punctuation is ignored is predictable and provides a solid basis for manual adjustment. Any alternative suggested should be at least as predictable.

The LilyPond issue is not the same at all. It's just a very simple "ignore punctuation" request. What you are asking for here is much, much more complex - actually parsing the lyric to find matching pairs of parentheses and ignoring the *text* within thos ematching pairs. It's an incredibly minor / obscure request compared to simple ignoring of leading punctuation, which we already do.

Your example in particular has nothing to do with ignoring the punctution itself - you are asking for the *words* within the parentheses to be ignored. But logically, that's just a separate element - it's not really part of the lyric at all.

Again, we *already* ingore leading punctuation. We just don't ignore *text* that happens to be surrounded by parentheses. neither does LilyPond, and nor do I think it's particularly reaosnably to expect. You should add that parenthesized expression as a separate element.

This example and the LiyPond example are diffewren tin that are are *completely unrelated*.

Again, the LilyPond issue is about ignoring punctuation charcaters. it isn't abut ignoring *regular letewrrs that happen to be surrounded by punctuation characters*.

I get what you are asking for - some sort function that figures out when the punctuation or spaces you have used are meant to indicate that a portion of the lyric isn't really part of the lyric but some sort of aside that should be ignored when it comes to spacing. There's no way one could come up with an algoirthm to figure out exactly when that is what is meant and when it is not. Not all cases of embedded spaces within a lyric, for example, are meant to indicate what you are showing here and thus; some of the case it would be 8wrong* to ignore the first word. Other times it would be the *last* word that should be ignored. There's just no possible way to get this "right" all the time. Which is why I keep saying the *right* way to do this is not to try to trick MuseScore into treating those as a single lyric in the first place.

MuseScore can't base on layout on the order you type things; that information is long gone after saving.reloading the score, for instance. Nor would it be easily discoverable. The idea that MsueScore detect matching pairs of parens and special case the text within them makes more sense - it's just not as easy as you might think given all the corner cases that could crop up.

Not saying it will never happen, but I'm still not convinced it's the "right" solution to this type of problem anyhow. Something like the "lyrics verse" element that we had for a little while - a sepparate piece of text that you attach to the main lyric - would be better. There were just too many problems with the implementation, and it was too hard to discover / cumbersome to use for the basic purpose it was intended for - numbering verses. Maybe we could consider adding it back in a different form to better handle this your example here.

But meanwhile, it is simple enough to get this result by placing a second text, assdigning it lyric style, and then adjusting the alignment and adding whatever manual positioning might be needed.

It's still a whole new complication to the internal representation of the score, and a complication to the UI, to handle a corner case that is easily handled by other means. Again, maybe someday in the distance future this will be worth worrying about further.

Manual adjustment would be trivially simple. See the alignment to left or right as appropriate, nudge a few pixels to center. It would survive relayout better than many manual adjustments as it is.

But again, the whole problem is your insistence that something that is most definitely *not a lyric* be entered as if it were, and then asking the lyric layout algorithm to special case that not-a-lyric it was never designed to handle in the first place. As I have said, there are better ways of doing this than trying to shoehorn it into lyric layout.

So no, I don't think we are agreed on a method. I think the most natural way to implement this is as a totally separate element, as I have explained already. For now, as an ordinary text that you assign lyric text style to and position as you see fit, but at some point in the future, maybe we re-introduce something like the "lyrics verse" element to handle this very special case with a little more automation.

Meanwhile, if you are dead set on shoehorning this not-a-lyric into the lyric, you can do it as I described above with only a small manual adjustment required.

Actually, a reasonable straightforward way to do the shoehorning with no artificial intelligence or guessing required would be a tickbox "Align based on last word only" in the Inspector.

I know you want MuseScore to be LilyPond, with everything figured out automatically and no manual adjustment require,d but oyu have to realize that is just *not* the goal of the program. One of the wonderful things about a WYWIWYG program is how easy manual adjustments are. That's a strength, not a weakness. The program does as good a job as it can while still maintaining quick response time, you take over from there if your needs are more specialized. As I said, assuming you first set alignment to left or right as appropriate the *amount* of the adjustment required to do the centering is small enough that it is extremely unlikely to be an issue in practice. Have you tried it? You're making a big deal about something that is virtually inconsequential.

Anyhow, the fact that the parenthesized thing mgiht not be "not-a-lyric" is *precisely* my point. In your particular case, it happened to not be a lyric - it was instead a direction to the vocalist. In other cases, though, it might well be part of the lyric. That's why I don't think it makes sense to try to guess. MuseScore shouldn't be in the business of guessing what you meant.

As for radio buttons in Inspector, well, again, you can't solve the world's problems automatically. There is a reaosnably clear use case for "last word": instructions such as your example, also things like "Figaro: Si!". Use cases for other configurations are less clear. And what if there are more than three "words"? In theory, there could be arbitrarily complex sequences of characters in a lyric. In practice, reasonable people don't expect computer to handle every possible case automatically. Cover the cases worth covering and move on to something more important.

OK, so between that and the real solution, which is to provide something like the "lyrics verse" to allow you to create these directly, we at least have a plan for something we could look at in the future.

as 2.0 is released...

See https://github.com/musescore/MuseScore/issues/15347