Space is not made for multiple verses in continuous view
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
As shown in the picture, when entering lyrics in continuous view, there is no space made for adding more than one verse. The picture is from an actual score, but testing a new score with default values had similar results.
Fix version
3.5.0
Comments
Seems none of the things that should spaced staves work in continuous view - eg, notes way above/below the staff will overlap the previous/next staff as well. I guess it's an open question as to whether continuous view should force staves to be as far apart as they need to be on their widest system - occasional overlaps might be OK - but lyrics seems like they should be handled. That much at least worked in 2.x
Surely not minor, possibly even a blocker?
This was an intention to turn off autoplacement in continuous view. It improves performance and still is suitable for note input. Enabling autoplacement in continuous requires more work to interpret one loooong system correctly.
So, this is the issue, indeed, bit not the priority.
PS. Workaround for this particular issue is to manually adjust the distance between the staves.
In reply to This was an intention to… by Anatoly-os
I do use spacers to work around this issue in continuous view. That's why I put in #279117: Cannot add custom lines spacers to custom palette. I'm not suggesting auto placement be implemented in continuous view, just put enough space between the affected staves to make room for verses or make the other issue a priority so I, and others, can create our custom spacers as mentioned in the other issue.
Reported also in #280071: V3 Beta problem with continuous vs page view. Worth thinking about possible solutions. We don't turn off autoplace completely - elements still do their normal collision avoidance, I guess just the part about staff spacing is not done. What if this were done just for the measures currently in view? Could be disconcerting to see staff spacing change as you scroll. Another possibility is to simply add some fixed amount of extra space below staves with lyrics so it's not a problem as often.
Came up again: #287037: Lyrics Overlay Staves in Continuous View
I had a thought - since Shift+drag no longer works as a synonym for "Extra distance above staff: anyhow (by design), what if we instead made that action have that effect only in continuous view? So it would take effect score-wide, but you could easily pull staves closer together in sections where they don't need to be as far apart as they do in other places (and vice versa). I generally don't like actions that are mouse only, or ones I can't control more precisely (eg, via an actual numeric setting), but since this is only about the current view and not really a score setting per se that would affect page layout and thus doens't need precise control, I could live with it. We could always a separate field to staff properties for this too I guess.
Just a quick note here that this issue persists in 3.1 RC.
@Marc, Perhaps making the shift+drag a staff affect only continuous view would be a good way to allow the user to easily adjust the space. For the most part, I expect that this space will be consistent throughout the song, but could be easily adjusted if needed with your suggestion.
@toffle, it looks like Marc is working on ideas to fix this. Feel free to suggest other options. I am only one user and welcome other opinions. A related discussion is happening at #279117: Cannot add custom lines spacers to custom palette
Right now I'm thinking three things, and I can't decide whether to do all three or just a subset:
1) change the default to be more like 2.3.2, where even one measure that requires extra space forces extra space by default throughout the score
2) implement spacers that work in continuous view only
3) allow Shift+drag to add/remove extra space
All three could work together. For 1), I would want to see if the performance hit is too noticeable. I think 2) and 3) work together nicely in that the actual effect of Shift+drag could be to change the height of the first continuous-only spacer found, or add one to the first measure if not. That way there is a "paper trail" and you can be sure of getting back to the default by removing the spacer.
Shoot, just realized there are two parallel issues here on the same topic. See #282579: Continuous view needs space for lyrics. One should probably be closed as a duplicate of the other. Preference?
I marked the other, newer one, the duplicate. There was no compelling reason to keep it over this one.
relates to #272135: [EPIC] Continuous view issues
In reply to Right now I'm thinking three… by Marc Sabatella
If you make Marc's May 24th proposed adjustments in spacing to the Continuous view, what will happen to the lyric-stave spacing when the user returns to Page View or Single Page?
Am I correct that this problem affects only MS2 files imported to MS3, but does not affect files created in MS3?
It is now July, and there seems to be no progress on implementing what MS2 did so naturally: maintain the same spacing of lyrics and staves in both Page View and Continuous View.
When may we hope for MS3 to behave accordingly?
-Tom
I made three separate proposals in https://musescore.org/en/node/276141#comment-921401, not sure which of these you mean or if you mean another still, but in my mind, anything spacing done in continuous view should stay in continuous view.
In reply to I made three separate… by Marc Sabatella
I ask because spacing changes in one view typically propagate to the other views as well.
I posted essentially a related thread last night, not knowing this one was still active after so many months: https://musescore.com/groups/59271/discuss/5044248. However my issue was not about multiple verses, the title of this thread, but about single verses being mis-spaced in files imported from MS2 into MS3, which I originally posted back in January: https://musescore.org/en/node/282579.
Attached is my test file that illustrates the problem I reported in January, and again last night.
Should my 5044248 post remain its own thread or are the issues one and the same with the above post?
Continuous view is continuous view regardless of if the score was created in version 2 or 3, so I don't think there should be any special considerations for imported scores in continuous view beyond ensuring manual adjustments are properly accounted for according to the option selected when the score is opened.
Marc's goal on May 24th was to have a special set of spacing permitted to affect continuous view only, and everything he says is that these adjustments would be retained if the user went from continuous to page and back to continuous view with no effect on page view. For those of us who prefer continuous view, I think this would be a good way to do things.
MS 2 added a set space between staves that affected continuous and page view the same, except in page view there was only space for 4 verses if there were 4 verses in the system. This was almost the full extent of auto avoidance in version 2. I wouldn't object to version 3 doing basically the same thing. Just make room for the verses and let the user worry about anything else.
In reply to Continuous view is… by mike320
That sounds fine to me, so long as MS3 behaves the way MS2 did, and keeps lyrics spaced the same distance from staves no matter what View was selected when MS2 files are imported into MS3.
There will often be a different distance between staves due to other things, but the distance between lyrics and the staves should be determined by the system settings in continuous view with no other auto avoidance). This was basically the original request.
That works for me.
What is the reason that MS2 files, like the one I attached, end up looking so bad in MS3's Continuous View, and not on Page View or Single Page?
If you mean Test of MS3 Lyric Bug.mscz from earlier today, then I only see a version 3 score. To truly understand I would need to see the version 2 score and know what option (y/n) you selected on import. At first glance I would say the main problem is the 4.5 spacing between staves.
And that should be fixed already if you reimport, 3.1 and later adjusts the lyrics bottom distance to make more sense. If that doesn't help, please start a new thread in the Suppot forum here on musescore.org so we can understand and assist better.
As for the actual issue at hand, unfortunately there is no way for MsueScore 3 to go back to the "dumb" algorithm of MuseScore 2, allocating space for lyrics but nothing else. Now that other markings are part of the skyline too, it's all or nothing. Which is probably fine. I did look at implementing this, it's doable, but slows things down for sure.
In reply to If you mean Test of MS3… by mike320
Mike320, you are right.
Here is the MuseScore 2 version of the file, so you can see what importing it into 3.2.3 does to the lyrics in Continuous View.
-Tom
In reply to And that should be fixed… by Marc Sabatella
Marc,
Importing to 3.2.3.22971 shows the problem I am reporting, with lyrics superimposed over notes on staves.
I started a thread for this on January 23rd: https://musescore.org/en/node/282579
I started a 2nd thread on the same problem July 8th: https://musescore.org/en/node/291931
Are these sufficient?
-Tom
Those are sufficient if those are the only scores you are having problems with, I will respond there.
Meanwhile, let's keep this thread focused on the suggestions of ways to improve spacing in continuous view.
tomfeledy, I have looked at your file in versions 2 and 3. You are correct that there is no space being made for lyrics at all. In version 2, you have the staff distance set to 4.5 with 2 spaces above the lyrics and 4 spaces below the lyrics and these settings seem (from looking at them) to be honored and sufficient space is placed between the staves in continuous view to allow for this minimal spacing.
I realize you are not complaining about this, but I'll point out that items like the tie in bass line are getting rather close to the lyrics above and would actually overlap those lyrics if you made the note an F above that. Also if you put text above any of the singers, it would almost touch the lyrics above. These, I realize, are acceptable intrusions into the other staves.
Version 3 totally ignores the minimum distances between staves including lyric margins in continuous mode and I think that is the real issue. I believe that taking these settings into account would probably be the easiest way to fix the overcrowding in continuous mode. It would be very acceptable to me and I expect far easier than creating special spacers for continuous view only.
On import, the lyric margins are totally ignored no matter which option you choose when importing a version 2 score and I consider that a bug. Choosing "no" should take these margins into consideration. I do realize there is not an exact 1 to 1 relation between every page setting, but it would not be too difficult to compare those that affect (grand) staff distances and apply them to imported scores when "no" is selected.
The reason we stopped trying to interpret the margins is that they mean vastly different things between 2 & 3. In 2, you needed to set the margins artificially high to work around the lack of automatic placement. But now those same margins end up creating far too much space, and we got countless complaints about that, so we fixed it to reset that. I tried for a while to come up with an algorithm that could guess at a setting that might approximate the old behavior, but it's simply not possible given the fact that spacing is no longer fixed even without considering lyrics. In the end, it's just going to be expected that you might need to adjust the spacing in some cases if the new defaults are not to your satisfaction.
As for the spacers, I realize it's not ideal, but as I said, I was not happy with the performance impact of actually honoring the skyline. It's possible the is some clever way to get around this, though. One would be to not actually use the skyline normally but to simply calculate the min and max values. It will result in too much space being allocated in some cases, but maybe that's better. Another potential thing to try is calculate the full spacing only when first switching to continuous view and then only the portion that changed on a given update. The problem is, all these data structures are organized by system.
In reply to The reason we stopped trying… by Marc Sabatella
Perhaps I am mistaken, but it does not appear there is any agreement on what steps, if any, will be taken to resolve the problem MS3 has displaying MS2 score lyrics in Continuous View.
Until this problem is addressed in MS3, what do you suggest users to do with their MS2 scores to get their lyrics show properly in all Views of MS3?
After all, I have a hundred or more MS2 scores that I'd like to import to MS3 so I can stop using MS2 for good.
What do you suggest I do with all my MS2 scores so MS3 users can see the lyrics properly in all views?
For continuous view, the only complaint ever concerning lyrics is that they end up being written inside the staves below. There needs to be enough space for them between staves. You've done a lot to make page view much better and that's appreciated by all who benefit from it.
Marc, you're trying to over-complicate things. In continuous view if you look at the lyrics height, the top margin, the bottom margin and whatever the space between verses is (I couldn't find a setting) and add those together. If they're greater than the distance between the staves, use that space between the staves, if it's less use the min staff distance. I believe there is a road map that tells how many verses are used, so you can make that the consistent space between staves. There are places this will be too much, like in the refrain, but we can make a reasonable argument for users to understand why this is the way it is. There is currently no logical explanation I would attempt to give a user.
This will make Continuous view usable as a tool if someone wants to follow along in a song and not have the sudden page turn of page view. For a vocal score, this is next to impossible at the moment without the user being forced to insert a system spacer they don't want in page view. There is also not a bunch of recalculating distances to slow down continuous view. A one time calculation every time you draw the screen wont slow things down too much.
As to what to do with version 2 scores? Keep them in version 2. That's always been my best answer and I stick by it. Versions 1, 2 & 3 can coexist peacefully next to each other, there's no need to "upgrade" a score.
Hmm, you may be on to something, but I'm afraid it's still not that simple. We could certainly get a generic value for the height of one lyric line, multiply it by the number of verses, and add the margins. However, this would a) not recognize that the generic height might not be accurate depending on font and whether the lyric contains extra-large characters (like Ä), b) not account for manual adjustments, and most importantly, c) not account for the fact that the lyrics themselves may be lower than the top margin indicates, because the whole line of lyrics is moved down if one note is below the staff. So while this sounds nice, I just can't see how it could work reliably.
In 2.x we actually did a whole extra calculation to figure out the distance needed for lyrics, but that's gone now, replaced by the skyline calculation. We don't need all of that calculation, but since the lyrics themselves are correctly honoring the skyline (in most cases, anyhow - it's possible to perform edits in an order where the lyrics will overlap the notes they are attached to until the next full relayout, which is probably a new regression with my changes to 3.1), we could make a pass through the lyrics just looking for the lowest one.
If we do that, it is tempting to just search the skyline itself and find the lowest point, lyric or not, so this benefits instrumental scores as wel, which is what I proposed just above. Unfortunately, it doesn't work unless we actually build the whole skyline, and thus give up some of the performance wins of 3.1.
Still, like I said, you may be onto something. There may well be a cheap way to get a good approximation of the space required for lyrics alone. I'm continuing to think about this.
BTW, I said I wasn't comfortable with the amount of performance we give up to actually do the skyline correctly in continuous view. It's possible I can improve on this further, but meanwhile, anyone on Windows who wants to test my initial attempt at this (from a month or so ago), give this a shot:
https://ci.appveyor.com/api/buildjobs/oj4eyionaaldctwf/artifacts/MuseSc…
As far as I recall this build works just fine, but it's noticeably slower than the current builds. Not as bad as before 3.1, but to me, bad enough. On the other hand, maybe others will consider it a fair tradeoff.
Does this problem happen with lyrics in Continuous View even when a score is created entirely in MS 3?
Yes, as discussed throughout this thread, the issuenis simply MuseScore 3 does not choose to.add additional space between staves when in continuous view, period. So not just lyrics but any elements far above or below a staff can choose with the next. And the reason, as explained, is that we want continuous view to be fast, and figuring out how to add that space slows things down.
The assumption has been that continuous view is primarily used for efficiency during note input, so speed is more important that prettiness, and all that really matters is the final result in page view. And that they can always use spacers to add space while they are working and remove them when finally done.
So now we're trying to figure out alternative approaches that will allow people to use continuous view in other ways without needing spacers, or at least without needing to remove them when switching to page view.
And another one in https://musescore.org/fr/node/286692#comment-946981 (french forum)
Translation:
As far as I'm concerned, I always work in continuous display, the scrolling is simpler: left and right, neither up nor down.
The switch to A0 is clever, and is a good workaround to the lyrics bug that overwrites music lines. But it still has two disadvantages:
- It reduces the need for downward navigation by extending the staff; but without completely eliminating them, as in the case of continuous display.
- It is always necessary to juggle between A0 and A4 formats, depending on whether you are editing or printing.
In conclusion, fixing the bug is still desirable, if possible....
Sincerely
I never got any feedback on my possible fix, I'd love it if people could test my build in https://musescore.org/en/node/276141#comment-933072
The holdup for me is, while it does fix the issue, it comes at a performance penalty, and I know people are also very sensitive to the speed of continuous view. As someone who almost never uses continuous view, and doesn't tend to work in scores large enough to notice performance problems, I really don't have a good feel for the tradeoff. So I'd need to get some good feedback on whether my approach here is acceptable or not.
Thanks for the reminder of this build/possible fix. I hadn't seen it. The message has been passed on.
In reply to And another one in https:/… by cadiz1
Hi,
@Cadiz : thank you for the pointer to my post, and the translation. As well then as for your help in the french forum, with the installation of the nightly.
@All : the nightly works fine, and fixes the bug. Maybe it would be fine to include the fix in a release to come.
Best regards
The problem is, it is not a bug but a deliberate design decision, because the alternative makes continuous view slower. The question isn't whether my change works or not - I know it does. The question is whether it makes continuous view too slow, for the people who have large scores that already tend to be slow.
In reply to The problem is, it is not a… by Marc Sabatella
That's what I tried to tell the user. But, of course, it looks so much like a serious bug (lyrics overlapping with staves) that it's hard to understand that it's on purpose! :)
In reply to The problem is, it is not a… by Marc Sabatella
Hi,
"A deliberate design decision"? Well, I understand the response time issue, and am not suggesting working it out is easy. But from a purely continuous-mode-user point of view, I'd then suggest to seriously reconsider this decision! In a classic voice/piano score, with three lyrics lines, lyrics completely superseed the right hand staff. In practice, it makes continuous mode definitely unusable :(
Regarding response time, I didn't notice anything. But it may not be conclusive, this was a short score...
Best regards.
In reply to Hi, "A deliberate design… by Lapiz_Lazuli
Just seeing Cadiz' post, that was apparently posted at the same time as mine.
Without consulting each other, we say the same thing...
The workaround is very simple - just add a spacer. I agree it would be better if it just worked, which is why I implemented the change I did. But again, performance is important too, and so far no one has given a definite answer as to how to prioritize these conflicting goals.
In reply to The workaround is very… by Marc Sabatella
I agree, performance is key to using applications, and the spacer fixes the issue, thank you. Provides manual spacing for continuous mode...
EDIT : provided though that the space by the spacer in continuous mode, does not exceed the automatic spacing in page mode. Otherwise, unless I'm missing something, a single system in page mode would be spaced differently from the others. This is minor, the workaround remains very manageable...
In reply to Surely not minor, possibly… by Jojo-Schmitz
Yes a blocker for me!
not a blocker at all, if all it takes is to add a spacer
In reply to The workaround is very… by Marc Sabatella
The spacer increases the distance between staves massively compared to version 2. As I use continuous view for teaching, and sight-reading when there are more than two or three staves it won't fit on the page! It's just very messy. Sticking with version 2 for me and my students until something is fixed as I can't use both due to file compatibility!
the spacer increases by exactly the amount you define (you set its lenght), and that should not be to set to more than needed.
Yes, as mentioned, a spacer gives you complete cont over the spacing - that’s the whole point. They really do provide a quite simple solution, no need to saddle yourself with the limitations and bugs of older versions. I guarantee the improvements in MuseScore 3 will save you much more time than the few seconds it takes to add spacers costs!
If you’re having trouble figuring out how to use spacers, best to start a new thread in the Support forum and attach your score so we can understand and assist better.
In reply to Yes, as mentioned, a spacer… by Marc Sabatella
Hi,
I must say that the spacer workaround very nicely fixed the issue for me :)
In reply to Yes, as discussed throughout… by Marc Sabatella
How about the ability to create a spacer which specifies a "minimum" spacing value, rather than an "additional" amount of space. My hope is that such an approach would not create much of a performance load, though it would require determining the largest "minumum space" for all the measures currently displayed in the continuous view. I also suspect it would generally alleviate the need to remove those same spacers when switching to page view.
I much prefer to use continuous view to create "Rehearsal Videos" for my choir; as long as the view doesn't fit an exact # of measures, it creates a predictable way for the singer to "read-ahead" and know what the upcoming note(s) will be, and allows me to create more condensed videos (still readable on a small screen, such as a smart-phone,) and smaller in overall size.
I haven't yet done my homework on spacers (I did attempt to change the overall score settings for system and staff spacing, but apparently didn't get that right either.
Spacers do create a minimum amount of space. But yu have to choose the amount of space yourself. It would be pretty easy is to have a command that inserted a spacer the right size for the score as it currently is, so as long as you didn't later add verses, it would all work out well.
In reply to How about the ability to… by Jon Enquist
Ah, "spacers!," very nice; my only suggestion would be that when I insert a spacer at the beginning of my song, (sufficient for all 4 verses in this case,) that when I get to the refrain (one set of lyrics) and add another spacer, that it would default to the current setting, and if I chose to shorten it, the new shorter value would be used instead.
In reply to I had a thought - since… by Marc Sabatella
It is now July 2020. The debate continues in this forum while no progress has been made on the problem of mis-spaced lyrics in Continuous View.
Continuous View is the most efficient way to quickly correct scores without having to jump from one system to the next. It is also the easiest when practicing music at home because of smooth, continuous left-right scrolling when in Play.
I agree with Marc's suggestion a year ago: Return the Shift-Drag functionality to Continuous view so we can quickly fix the mess MS3 creates in Continuous View, as shown in my attached files.
Will this problem ever be resolved? How long must Continuous View with lyrics remain unusable?
Earlier I posted a test build and repeatedly asked people to try it out and report on well it works for them. No one seemed interested, so I assumed it wasn’t a priority for anyone. Feel free to go back and try it out now. It’s too late for 3.5, but certainly something could be considered for 4.0. Maybe earlier, if people do dem on strays they care about this issue by helping out in this way.
In reply to Earlier I posted a test… by Marc Sabatella
" Return the Shift-Drag functionality " ie: #279701: Shift+drag doesn't move staves anymore
+1 (EDIT): +100!
I don't have the same use case, but frankly, I don't always understand this so natural function, anchored in the habits of version 2, is still not restored. What could be the harmful effect? We are told that we no longer need it because of the automatic placement.
This is not true. For my case of frequent use, standard staff + TAB, systematically, one cannot enter the low E with the mouse (it lacks space). #185056: Inability to enter the last note E with the mouse in Guitar + Tablature template.
Here again, you can either type with the keyboard (except that by default, it's the E of the first string, so you have to do two Ctrl + arrow down maneuvers to get there), or by typing the F and then going down a semitone. This is an additional manip. that must be repeated for each new similar note.
Then we are told that we can make this setting via the contextual menu, right click + change the value more or less randomly (the Apply fails and it is not done in real time), and then finally close. It's so tedious to repeat that each time. And all are kind of workarounds, no more.
We are also told that we can keep a template. All this is true.
Except that, in my case, I don't use many templates, because I've been doing hundreds of tests, almost certainly thousands of tests in this configuration since several years and in various periods of program development and I'm really tired and edgy of no more having this Shift + Drag feature so obvious and so useful and so fast. In short, a very bad point for that!
I’m not sure the shift+drag proposed here would help in your case which as you say is different. The version discussed here would be a special command only for continuous view and would not affect page view at all.
For your use case, maybe it makes more sense to find a way to not require extra staff space in the first place, so you don’t need a workaround at all. Like, change the way we calculate which staff you are trying to click on if one of them is a tab staff. Seems that would fix that problem with no need for hacks like increasing space.
Probably better to follow up in the other issue.
In reply to I’m not sure the shift+drag… by Marc Sabatella
Done: https://musescore.org/en/node/185056#comment-1010493
As a side note, I don't really understand why you call it a hack. And why would a hack be a bad thing in the first place?
Nobody complained about it in version 2, and now there are a lot of features in version 3 where you can move elements with the mouse (notes, horizontally, to add space between them), lines, eg voltas and others with modification of the anchor. If I believe the spirit of these new implementations, it's the intuitive character of these behaviors that's been put forward here.
This consistency would be reinforced: if you want to add space between two staves, you could also do it with the mouse (+ here the Shift key).
I call it a hack because you shouldn't need to have larger than usual space between staves just to be able to enter notes. It should work with standard spacing. So I’ll think about it.
In reply to Earlier I posted a test… by Marc Sabatella
Marc,
I tried to get to the test build from the link you had posted, but got this message instead.
-Tom
Yes, I think they might only get kept around for six months or something, unfortunately. And probably that branch wouldn't build anymore without work as much has changed in the past year.
It's disappointing to have not received feedback back when I spent several days working on this, but my sense was, it probably would not have made people happy on large scores because it would have made them as slow as MsueScore2 rather than ten times faster as it otherwise is. The extra few seconds saved by not having to manually add a spacer would be peanuts compared to the amount of time wasted on every layout as you continued to edit the score, most likely. I don't want to see us go back to the bad old days of big scores being unusable in MuseScore. So I'm not so sure the approach I took there would be a win in general,
In reply to Yes, I think they might only… by Marc Sabatella
I will do some more reading on this thread, but again my main complaints were:
1) The "spacer" function did not default to the current spacing; hence, any attempt to move to cursor between the default space and the current space produced no result at all. It was not apparent that all you could do was to increase the default space.
2) All you can do is increase the default space. (You should be able to decrease it, else the definition of a "spacer" is incomplete.)
-Jon E.
(if you have any work available, I am old enough to know better, but young enough to beg...)
P.S. Since you went commercial, I have not been paying much attention to this thread. My desire is to help, and I suspect the competition is much higher priced (our old church pianist was complaining about that.) However, I still love this product, even though COVID-19 has made it currently useless for me, since there are no choir practices.)
In reply to Spacers do create a minimum… by Marc Sabatella
Spacers do not create a "minimum," they are only able to increase the current minimum. I would appreciate if they could reset the current minimum to a lesser value.
I’m not understanding your point about the spacers - while it true they don’t default to the current space, it takes only seconds to make that happen. And for the record, yes, spacers can decrease space, just use the “fixed” spacer type. And actually, those do already default to fit the current space. You can also easily add a customized spacer back to the palette for easy reuse.
BTW, I have no idea what you mean about going commercial. MuseScore is 100% completely free - always has been, always will be. Maybe you are thinking of the score sharing website musescore.com? there are paid accounts there, but that’s not true, that’s been the case for at least a decade.
In reply to Yes, as mentioned, a spacer… by Marc Sabatella
As of my last attempt, a "spacer" does not give complete control at all, since in CANNOT DECREASE the current spacing.
See my comment above - simply add the "Fixed" spacer type. It absolutely can and does decrease spacing if you ask it to.
Although that's kind of irrelevant to the topic at hand, because decreasing spacing is never going to help avoid the problem being discussed here (lyrics overlapping the next staff). But fixed spacers can increase space too, and as I said, they size themselves automatically when you add them, so they are a good choice here no matter what.
In reply to Yes, I think they might only… by Marc Sabatella
Marc,
1) What are you referring as "slow" with regard to large scores in MS2? I'm not familiar with this problem.
2) What is the current solution to mashed up lyrics in Continuous View - just avoid using that view?
-Tom
Then you never had a large score
In reply to Then you never had a large… by Jojo-Schmitz
No, I have mostly choral scores of maybe 10 pages length. What is "slow" - the on screen rendering, or the playback?
screen rendering, changing a single pitch taking 2-10 seconds
Maybe you haven't worked with large scores, but they were almost unbearably slow to work with. Like, you'd try to enter a note, maybe 10 seconds after you clicked it would appear. Every single edit would take a looooooong time. This was a huge problem that caused many to practically give up. The cause was that we did a complete layout of the entire score on every edit, so the bigger score, the slower it was to work with. One of the major advanced in MuseScore 3 was only laying out the portion of the score that has changed, which allows large scores to be 10, even 100 times faster to work with. But one of the prices of this is, we no longer have complete information about the full score layout to work with when deciding how much space we need between staves in continuous view. I had been trying to find a way to retain "enough" information to automatically add space, but I couldn't find a way to do it without basically laying out the full score on every edit again, which would have unacceptable to most people since there is no good workaround. For now, spacers take only seconds to add and work around the spacing problem in continuous view quite well, which I guess is why more people haven't been complaining and why no one seemed interested in trying out my test build last year.
Not that we won't ever revisit this, but it's a question of priorities. Right now the main priority is getting 3.5 out, after that we can perhaps return to finding additional solution to this issue above and beyond the one (spacers) that already works well.
In reply to Maybe you haven't worked… by Marc Sabatella
Marc,
Thanks for the explanation. I now have a much better understanding of the whole problem.
Too bad the files formats are not backward compatible. If they were, perhaps small score users like us choral types could keep using v2 to do our stuff while big score users could use v3 for speedier editing.
-Tom
What prevents you from doing just that? Still seems like an awfully big sacrifice - giving up the incredibly huge advantages of MuseScore 3 just to save five seconds to add a spacer. But it should work just fine to keep using 2 if you don’t mind spending 100 times more effort on other manual adjustments to overcome its many deficiencies and limitations that 3 would have solved automatically.
I've been giving this more thought, and have another idea to run by people, hopefully I'll get enough response to gauge whether it's worth trying:
The simplest version of the fix I had implemented last year simply did the full automatic spacing calculation, and while it wasn't quite as slow for large scores as MuseScore 2, it definitely was a huge step backwards in that sense. Unfortunately my attempts to make this "smarter" - only doing the calculations where needed - caused other problems that would have been difficult to solve.
But I do see was way get something better than today at least, relatively easily. That would be to do the full spacing calculation only when entering continuous view, then simply remembering that spacing for as long as you remain in that view. This would allow people to really only want to read the score - or make relatively minor edits - to work as before, with no performance penalty whatsoever on large scores. So no adverse effect except maybe switching to continuous view gets a little slower, but there was already a full layout being done then, so the extra calculations here probably wouldn't matter that much
The limitation of course, is that if you then tried to actually add new verses while in continuous view, no new space would be allocated. Similarly, if you deleted verses, the space wouldn't be reclaimed. But, you could easily set things right by quickly switching to page view and back. Or, as now, adding a spacer. So it still costs still a few extra seconds every once in a while, but at in many cases you wouldn't need this.
I think this much could be done without introducing any new commands, any new strings for translation, or any compatibility issues.
If I can get any sort of consensus that this would be worth doing, I can see about submitting a PR that maybe could be considered for 3.5.1.
I say it's worth a try, Marc.
-Tom
See https://github.com/musescore/MuseScore/pull/6307. This actually does allow the space between staves to grow as needed while editing. II don't think this will cost much in performance on most edits after all. Only doing what is needed to be sure we can actually shrink that space automatically when no longer needed would really slow things down. If it turns out that the performance hit is still too high, it's very easy to change it to not grow the space as needed but only calculate it once when initially entering continuous view.
Please, I need people to help test this and if possible do so on the largest score you can.
Windows build: https://ci.appveyor.com/api/buildjobs/uibb885njd1ta6i1/artifacts/MuseSc…
macOS build: https://github.com/musescore/MuseScore/suites/887944671/artifacts/10514…
(Linux build failed, not sure why, it built for me on my system)
Works OK for me on my largest 3.x score (40 pages, 160 measures, 15 staves, 3 linked parts), editing (like changing a note's pitch) is slightly slower (i.e comes with a slight delay, a tiny bit more than in 3.5 Beta) in continuous mode, but bearable.
Enough space for the lyrics, so "mission accomplished" ;-)
But there sure are larger scores out there, so more tests/testers wanted
In reply to See https://github.com… by Marc Sabatella
Marc,
I get a 404 error at Github when I click on the MacOS link you provided.
-Tom
that link works for me, when clicking on it, not if copy/paste though.
Try https://github.com/musescore/MuseScore/pull/6307/checks?check_run_id=84… and then Artifacts
I tried the nightly with my transcription of Mozart Clarinet Concerto: 9 staves, 811 measures. Edits were definitely laggy in continuous view. I would not want to do more than a couple of edits. I tried to quantify it by moving a note with the up arrow key in time to a metronome. The highest speed I could manage was 94 bpm (or moves per minute).
System details are:
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.12638, revision: c320d50
HP Pavilion with Intel Core 5i @ 2.50 GHz and 8Gb RAM.
Is that nightly slower than the 3.5 Beta? It isn't for me (except for maybe a tiny bit)
Can you share that score? (I can't share mine die to copyright issues)
In reply to Is that nightly slower than… by Jojo-Schmitz
I can't tell any difference in response between nightly, 3.5 beta and 3.4.2 actually. I hardly ever use continuous view and never use it for editing, so I am not familiar with how it feels. It was an interesting experiment though.
Score is attached.
That's the important distinction though, the main question is whether this particular change impacts the performance in any non-negligible way. As far as I can tell it does not, so should be good to go into 3.5.
That score BTW doesn't benefit from this change at all, as there are no lyrics or other stuff that requires a larger staff distance in some systems. It doesn't suffer from this change either, so all is good IMHO
Even though the change mostly is intended to benefit scores with lyrics, it actually affects everything that autoplace normally does. So, space is also increased for notes or other markings far above or below the staff (except lines, these continue to not be autoplaced in continuous view).
So any benefits - and performance penalty - would affect all scores, not just vocal ones. Glad then to hear this one doesn’t seem badly affected!
That is why i wrote lyrics or other stuff that requires a larger staff distance in some systems. :-)
True enough! For the record, the skyline calculation and comparison would be the same
whether or not it turns to yield any difference in staff spacing. So any slow down would be seen even in scores that receive no benefit. Again, that’s good news if this score doesn’t show any noticeable difference.
BTW, timing with a metronome is clever and also nicely musical :-). My own tests have been with a stopwatch, enter note input mode on an empty measure, enter sixteen sixteenths as fast as I can, then time how long it takes for MuseScore to catch up.
Continuous view overall is still slower than page view but by nowhere near as much as before 3.1 (?) when I implemented the partial layout. And nowhere near as slow as MuseScore 2.
Fixed in branch 3.x, commit cd92ec6f01
_fix #276141: no space for lyrics in continuous view + collect_artifacts
Resolves: https://musescore.org/en/node/276141
A common complaint since the release of MuseScore 3 is
that we no longer allocate additional space between staves
for lyrics and other elements above/below the staff,
when in continuous view.
That's because these calculations in page view can be optimized
so they only need to be done for affected systems on each layout.
In continuous view, there is only one system,
so it would mean a full layout, which is very slow.
But MuseScore 2 did this, and people writing vocal music especially
were accustomed to this automatic staff spacing.
Since lyrics were about the only thing that did this spacing,
it wasn't as expensive as it would be using MuseScore 3 autoplace.
And yet, MuseScore 2 was extremely slow with large scores,
because it lacked any range optimizations, even in page view.
This change finds a compromise that should work well.
On the initial layout in continuous view, we do build a full skyline,
so it is easy enough to add space for each staff then,
and any performance penalty is paid only at that time.
Any extra space needed for this is remembered for subsequent layouts.
On future layouts, we do use a range, so we only have a partial skyline.
The code here calculates the space needed just within the current range,
but it also compares this with the remembered value,
so uses whichever is larger (and remembers this new value if different).
The result is that the spacing is correct when first opening the score,
or when first switching to continuous view.
After that, any edits that increase the required space
(such as adding a new verse of lyrics)
will do so as expected.
If you later make a change that reduces the amount of space requires,
we cannot reclaim that space, since a full layout would be required
in order to detect that we truly don't need the space anywhere.
But you can always reclaim it by switching to page view and back.
The code to do the partial skyline comparison is not free,
but it happens only once per staff per layout,
so in theory it should have a negigible effect on performance.
If this assumption turns out to be wrong,
we can switch to the code that skips the partial skyline comparison
except on the initial layout.
This is included but ifdef'ed out._
Fixed in branch 3.x, commit 05094e2c7c
_Merge pull request #6307 from MarcSabatella/276141-continuous-spacing
fix #276141: no space for lyrics in continuous view_
Fixed in branch 3.5rc, commit b0ef3983f5
_Merge pull request #6307 from MarcSabatella/276141-continuous-spacing
fix #276141: no space for lyrics in continuous view_
In reply to that link works for me by Jojo-Schmitz
Forigive my ignorance, but I have not used Github before. Where exactly do I find the MacOS file to download and run?
Too late, but in a good way I hope :-). The change is already merged and is in the current Nighty builds you can get directly from the Download menu above.
We could definitely still want you to test this to make sure it really is good to go for 3.5, but as of now, that’s the plan.
In reply to Forigive my ignorance, but I… by tomfeledy
No need anymore, grab a development build
In reply to Even though the change… by Marc Sabatella
Marc,
Can we have our cake and eat it too?
Can there be a setting in version 3 that branches the operation from one method to the other? That is, users with large scores without lyrics set the switch one way and they get good performance. Users with smaller scores and lyrics set the switch the other way and get good staff spacing with their lyrics, The slower performance will affect them much less, if at all.
Is such a setting switch possible?
-Tom
Such a thing is possible, yes, not for 3.5.1 since it adds new options. But it remains to be seen if it is even needed - I hope we find what I implemented works for everyone. Performance impact seems negligible in most cases. The only case where it might be more noticeable are on those edits that do for whatever reason trigger a full relayout of the entire score. For some reason, just moving the cursor up & down through verses triggers this. So it's already way slower than other edits, which makes no sense to me, probably we should remove the setLayoutAll() calls from this operation. My change means this particular operation - already slower than others - will be slower still. That's the one place I'd expect the difference to be possibly noticeable. Well, that and any other operations that currently do trigger a full relayout, but there actually aren't all that many.
BTW, if we do add an option to control any of this, I'd propose we also go ahead and include lines (ottavas, voltas, hairpins, etc). Right now these don't get autoplaced because it would be slow, so they will happily collide with notes, lyrics, etc. An option to say, autoplace everything in continuous view could be nice for smaller scores, then it could be turned off for larger ones.
As there doesn't seem to be a considerable performance impact, such an option may not be needed
Automatically closed -- issue fixed for 2 weeks with no activity.