Lyrics for melismas should not respace notes if there is room before next syllable
S4 - Minor
Steps to reproduce bug
1. Create a score with a wide melisma syllable or open the attached file: "melisma note spacing.mscz"
Expected behavior: Since there is room for the melismatic syllable to fit under all the notes is spans there is no need to increase the spacing between the first and second note
Actual behavior: There is an large, unnecessary space between the first and second notes
MuseScore version: r. 2942 nightly
(Operating System: Windows 7)
|melisma note spacing.mscz||7.76 KB|
Does the lower half of Capture.png created by lilypond?
Vanferry: Yes, I should have mentioned in the bug report that the top half is the original MuseScore file and the lower half was rendered via LilyPond.
Lilypond really has the best layout engine in open source notation software, hope we can learn from it.
I used to debug it under linux, but not in a comfortable way, not familiar with its development environment, sigh.
Excuse my bad english....
Its extremly important MS not allow text to respacing music for two reasons :
1/ Music's rythm is very less comprehensible
2/ It's generate unusable empty spaces. It's wasting... Bar 29 ie
engral, Critical priority is reserved for crashes or data loss so I moved the priority back to normal. Just to be clear the original bug report is about melismas (lyric syllables sung over several notes). You're example is different. Measure 29 has only one note for the syllable. It takes up a little more space because the lyric is centered under the note (as opposed to left-align). There is probably some space that MuseScore could save here, but it deserves its only thread, since this bug report is very narrowly defined.
This special case of melisma layout is handled better in r5100.
I think that this is the same example : lyrics respace rythm. And I never see this in scores between 15 years I'm engraving music. I never see that in contemporary scores AND no more in « old » scores (XXe). I never read in engraving's rules that was possible.
It's better to shift lyrics to the right or the left than respacing rythm. But shifting lyrics doesn't has any effect...
I hope new version of MS will correct this.
While waiting, I would konw how to left- or right-align lyrics. It seems that in dialog-box, there has no effect...
How can I obtain r5100 ?
It might look similar, but it is entirely different. Again, the original bug report had to do with melisma and melisma only. It woild be possible to change that without affecting your example one bit - that's how you know it is unrelated.
As for the nightly builds, see here: http://prereleases.musescore.org/windows/nightly/. There may or may not be something similafor Mac. But be aware, those are experimental builds, not intended for production use.
Hum... Sorry I don't understand what you mean in first paragraph...
My English is so bad....
werner, r5100 is a step in the right direction, but it still needs to avoid overlapping with syllables outside of the melisma. To make the note respacing less obvious it should be shared across all the notes of the melisma. See attached for a visual explanation.
engral: I created a new topic for you on the forum. Please continue our conversation in the new topic: http://musescore.org/en/node/14050
The melisma of the score in #10 is interesting.
It seems to show symptoms similar to this .
Using MuseScore 2.0 Nightly Build 1812015 - Mac 10.7.5.
It's possibly worth linking to this: #22696: Lyrics don't overlap stave elements
I gather that score was created in a very old nightly build though. Is it possible to recreate a similar situation from scratch in either 1.3 or a current development build?
The score is openable in 1.3.
The one in #10? No it isn't. It's version 2.0.0, mscVersion 1.23. 1.3 was version 1.3, mscVersion 1.14
Not saying it's impossible to recreate from scratch, but figuring out if it is possible and then doing so seems like the first step in the investigation.
It seems it has something to do with custom text properties - if I select all lyrics and then change style to something else and back again, the lyric and the extended return to proper position.
You're right, sorry.
Here's a recreation of the score in comment #11 using today's build, e2a6fbd (after 2.0 beta1).
The problem now is that some respacing of the notes is needed to avoid overlapping with the syllable several notes later.
Indeed. As far as I know, this is not a new problem - the same would have been true in earlier builds, although depending on the specifics, you might have needed a longer word to see the issue.
BTW, I had forgotten this code existed. Might be possible after all to adapt it to work for hyphenated melisma as well - see http://musescore.org/en/node/33071
David (& anyone else following this) - please see my response #6 in #33246: Hyphenated melisma requires too much space.
I am thinking the risk of collision that we have now is worse the potential wasted space / irregular spacing that was the case before the change to allow melisma syllables to overlap multiple notes. I am therefore proposing reverting the change made earlier, so that by default melisma syllables - whether created via extender or hyphen - *do* space the next note. I currently have an admittedly hacky way of forcing the lyric to overlap subsequent notes: put a trailing Ctrl+Space character on the syllable. This works for both extender-based and hyphen-based melisma. As is the case currently, you risk collision if you do this, but at least the collision doesn't happen by default.
If we like the behavior, we could of course opt for a more discoverable way of accessing it (eg, Inspector option). But I kind of prefer to keep it a bit more hidden, and then eventually find a way to do the spacing automatically. It's not trivial, though. As I mention in the other issue, there is code to do similar things for chord symbols, but it's complex and still not foolproof, and lyrics would be more difficult still because there are multiple verses and multiple voices to consider.
Here's my code:
should be fixed since ab15653
No, as mentioned in the comments for that PR, I undid the portion of the PR that would have addressed this,since there is no way to detect / prevent collisions.
Using MuseScore 2.0.2 Revision f51dc11
Is it not possible to detect when there is a melisma covering several notes *and* these notes are all linked by a slur? Then it should be clear how far the syllable can be permitted to extend.
See screenshot of the spacing problem caused by the syllable "stands".
Well, for one thing, there is no guarantee anyone would actually use a slur, or use it in that particular way, so I don't think it would be generally helpful to rely on slurs as a solution. But more importantly, the problem is that we do all our spacing basically one note at a time. That is, when deciding how much space to allocate after a note, we simply don't have a way to consider any greater context. We would need to come up with a new construct or changes to the spacing algorithm to make this possible, it seems to me. Once it is is made possible at all, *then* it would make sense to discuss how to expose this to the user. But for now, there just isn't way to make it happen. The syllable either affects spacing of the next note or it doens't affect spacing at all.
MuseScore 2 doesn't have the infrastructure to fix this problem. It would need a big change in the layout algorithm to be able to interleave several segments. Fortunately, MuseScore 3 has this infrastructure in place and this problem should be solved. I let the issue open and will try to provide a screenshot of the first sample rendered in MuseScore 3.
Came up again in https://musescore.org/de/node/260421
And again in https://musescore.org/de/node/118396
I imported my score https://musescore.com/user/12771361/scores/4864587 created with musescore-2.1 into musescore-master-20171221-1407-nightly and got the attached result for a bar with melismas.
All the hyphens and underscores are misplaced and furthermore the first underscore after "be-rauscht" is unnecessary, because the syllable "rauscht" already covers all the space provides by the two 16th.
Please improve this situation in the musescore3 snapshots.
TIA and Best Regards, Wolfgang
Not an issue in master only, but ever since, even in 1.x
Changed the version tag according to the Jojo's comment. 3.0alpha is used for the issues introduced in 3.0 development.
Is this still current?
I just downloaded latest and set up my build (and hunt for an issue that i can try to start working on) and this seemed like something fixable -- only to find I can no longer reproduce in master.
let's consider it fixed then
Automatically closed -- issue fixed for 2 weeks with no activity.