Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spacing of melisma syllables #1330

Merged
merged 1 commit into from
Sep 29, 2014

Conversation

MarcSabatella
Copy link
Contributor

Currently, syllables that represent melismas affect spacing differently depending on whether they have extenders or hyphens, but neither behavior is ideal, and the inconsistency is an issue in itself.

For syllables with extenders which are, by definition, always melismas), the syllable is actually completely ignored for note spacing purposes - deliberately. This allows the syllable to overlap several notes, but it also risks collision with the next syllable that does occur. See http://musescore.org/en/node/5261

For syllables that melismas but that use hyphens instead of extenders, the syllable is accounted for normally in spacing, leading to unnecessary space being allocated for the chord to which the syllable is attached but at least avoiding the risk of collision. See http://musescore.org/en/node/33246

This PR changes the behavior to be consistent. Melisma syllables of either type will be treated by default like the hyphenated type are currently - they will affect note spacing. However, I added a way to get the current extender behavior (again, for either type): simply add a trailing Ctrl+Space to the syllable. You still risk collision, but since you have to take this step manually, you take on that risk as well. While I was at it, I also made this same trick work to disable allocation of leading space and give a manual workaround (that is similarly use-at-your-own-risk) for http://musescore.org/en/node/22696.

The ideal behavior for melismas, BTW, is for the layout to automatically detect how many segments the syllables would need to overlap, and divide the required space equally among them. This is much easier said than done, however. It's akin to what is done for chord symbols, but that code doesn't actually handle all cases well either, and in any cases, lyrics are more complex because there are multiple voices and multiple verses involved.

@lasconic
Copy link
Contributor

I'm not a huge fan of this change :(

1/ The hack with the trailing space will be a nightmare in customer support
2/ Same hack will be a nightmare to support in future version.
3/ Regarding the fix itself. I agree that it would be better to have the same behavior, whatever it is. Avoiding collision automatically is better according to me, even if the spacing is "wrong".

As you said, a true solution would be something like chord symbols. I don't get the added complexity of having multi voices for lyrics. Even if there are several voices involved all the segments spanned by the lyric should get some space. Multiple verses is indeed a bit tricky.

@MarcSabatella
Copy link
Contributor Author

Fair enough. I'll disable the special case code for Ctrl+Space, so we avoid collision at the expense of some wasted space with long syllables. Same as 1.3. We could still consider adding a better way of disabling spacing for individual syllables such as via Inspector - the equivalent of a "local relayout" flag for lyrics. But we could worry about that later.

Regarding the true solution, the complication of multiple voices is just that for chord symbols, all the special handling is done after the loop through voices for a segment is finished. But for lyrics, we'd have to be figuring things out during the loop, and I haven't thought through what changes that might necessitate. No doubt it's doable, just not quite so straightforward to adapt the current code.

There are a few other concerns with adapting the chord symbol code, such as the fact that space is actually allocated unnecessarily in many cases because this is all calculated before stretch is applied. That is not unique to this chord symbol code - it's actually an issue with all the spacing calculations. But chord symbols and lyrics both have the potential to require a lot of additional space. I see the side effects of this with chord symbols but they don't bother me. Not so sure I'd feel the same with respect to lyrics, but presumably it would still be an improvement over the irregular spacing we would get otherwise.

@MarcSabatella
Copy link
Contributor Author

Behavior is now consistent: melisma syllables are no longer treated differently than other syllables with regard to note spacing. Which is to say, there is too much space if they are long, but no risk of collision. So basically, I "unfixed" http://musescore.org/en/node/5261. The code is still structured in such a way that Lyrics::isMelisma() correctly detects both varieties of melisma, so it would be easy to use it in the layout process if we decide to later (perhaps by checking a Lyrics property or Style option instead of the trailing space).

BTW, there were also a few issues with the layout of the separators that I fixed along the way in the original version of this commit; I left those fixes in place as well (that is the code in system.cpp).

lasconic added a commit that referenced this pull request Sep 29, 2014
@lasconic lasconic merged commit 6006fb6 into musescore:master Sep 29, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants