Batch Typesetting
Musescore is a great typesetting engine most scores, but it has the limitation of being 100% real time, unlike LilyPond, which can take the time to typeset the "perfect" score.
Being real time limits the computations Musescore can do before becoming really slow. On my machine it is already pretty slow when editing scores in Page View mode (it is very fast in Continuous View mode, though).
I'd like to suggest 3 features that would benefit from non-realtime typesetting:
1) Breaking the score into lines, trying to keep the spacing inside each line as even as possible. Musescore's line breaking is not even at all, especially if you insert a page break for some reason.
2) Adding space between staves that have dynamics or other elements between them. This should be feasible in real time, but in batch-mode we could use more sophisticated approaches like a skyline algorithm or something similar.
3) Placing notes in multiple (> 3) voices on the same staff. This is quite easy to do manually, but it would save some time if it could be done automatically. Again, this could be done in real time, but doing it in batch mode is probably easier.
The idea is that there would be a button / menu item you could choose from the GUI for each of these actions.
The program would then freeze and typeset the whole score (LilyPond-style) and unblock user interface again once the changes had been made.
I think Musescore is an amazing program, and I would never want to use LilyPond to edit a real score again, but I think we could use the best parts of LilyPond's batch approach for those adjustments that would take a long time to compute and are boring to apply manually.
Comments
Could you explain in more detail what you mean by 1 & 3?
In reply to Could you explain in more by Marc Sabatella
I think 1 may be about an idea for MuseScore to calculate automatically the ideal stretch that would be the same over all lines, right up to the end of a page. It's possible to end up with (say) two measures stretched to fill a whole line at the end of the page, necessitating manual breaks and stretch adjustments on multiple other lines to even things out. This could be an advanced option for Add/Remove Line Breaks.
In reply to I think 1 may be about an by Isaac Weiss
Yes, exactly. Musescore seems to use a greedy algorithm, that is, it breaks the line as soon as possible. This leaves uneven lines, with some lines underful, which leads to excessive stretching. I suggest using something like TeX's line breaking algorithm (http://www.bramstein.com/projects/typeset/). Because using this algorithm is computationally expensive, this can't probably be done in real time, and tha't why I suggest doing it with batch typesetting.
In reply to Could you explain in more by Marc Sabatella
ZackTheCardshark has explained point 1 already. I elaborate the point further in my reply to his comment.
Regarding point 3, i was specifically addressing the problem in this post: http://bartruffle.blogspot.pt/2013/09/lilypond-vs-musescore-in-polyphon…, which compares LilyPond with Musescore. LilyPond tries to displace the voices so they don't clash. Although it succeeds somehow, there are still clashes, especially related to ties and slurs. Musescore allows you do displace the notes manually for a result indistinguishable from LilyPond's, and makes it easier to solve the clashes. It would be cool if there was a way to displace the voices automatically, as it would allow the user to concentrate on handling the clashes that can't be handled automatically (e.g. slurs and ties).
This is not as important as point 1 (which for me is high priority), but it would save some time for scores with multiple voices.
The point of these features is to highlight the advantages of having a batch typesetting mode for Musescore, which would allow for more computationally expensive optimizations of the score.
In reply to ZackTheCardshark has by GEB
The link you posted seems broken. So I still don't understand what you mean. There have been some very significant improvements to MuseScore's layout since 2013, and MuseScore 2.0 already goes to great lengths to displgace notes according to standard engraving practices so as to avoid clashes betwene voices. While I'm sure some corner cases remain, I wouldn't look at at a blog post from 2103 to find issues. If you have specific cases you'd like to see improved, you should just post them directly here.
On the other hand, MuseScore does very little in the way of trying to avoid collisions between ties, slurs, articulations, text, and other markings. This is the sort of thing many people would like to see and does seem a good fit for a batch processing mode.
Your first suggestion regarding line breaks is interesting, but strikes me as a pipe dream. I doubt you'd ever get two people to agree on the optimum layout for any even moderately complex piece of music. For instance, in my world there is nothing wrong with ending a system with only two measures. I simply append a horizontal frame and size it to suit my tastes. But even if I took it on faith that a significant number of people would want to see that, I doubt they'd agree on many of the other specific questions that others could would be answer. For instance, I consider it nice to try to keep voltas intact. I also try to get double bars and rehearsal marks to line up at the end of systems. Others couldn't care less about this but go to some length to have a similar number of measures per system. Then there is the matter of optimizing page turns so as to avoid breaks during technical passages, or in unfortunate places with respect to repeats, multimeasure rests, etc.
All of this stuff is subjective enough that I highly doubt any algorithm anyone came up to try to improve on the assignment of measure to systems would be seen as an improvement often enough by enough people to be worth the effort. It is certainly possible someone could prove me wrong, but realistically, I think automatic collision avoidance is going to be much more valuable for most people.
In reply to The link you posted seems by Marc Sabatella
The correct link is http://bartruffle.blogspot.pt/2013/09/lilypond-vs-musescore-in-polyphon…
Sorry about that. I haven't tested that specific example in a recent version, though.
Regarding the rest:
Ok, I agree. You'd have to define penalties for breaking in unwanted places, which is easy for line breaking in texts but very subjective for music. But please notice that an algorithm that minimizes stretch between notes is very easy to implement, although it might be computationally complex. The user could add penalties to forbid and discourage line breaks in specific positions.
Of course it would. I didn't suggest that because I can't suggest a simple algorithm for this, unlike the line breaking problem, which is actually very simple from an algorithmic perspective. But I agree all efforts should be directed to automatic collisions first. They are a real problem when you automatically generate parts from a full orchestra score. Regarding collisions between ties and slurs, I think it is a lost cause. The LilyPond devs have been fighting that battle for ages, with little to show for it. But the rest is certainly doable with some effort!
I'd like to contribute, but I have 0 experience with C++ and little experience with C, but I'll look into it as soon as I have the time. Musescore is an amazing program, and I feel kind of guilty requesting features without contributing.
In reply to The correct link is by GEB
Regarding the example from that page - one thing we *don't* currently do especially well is three voices on a single staff. Currently, we assume all upstem voices should align, as should all downstem voices, which is what you want sometimes but not in most of this example - depends on your reason for using voice 3 in the first place.
Anyhow, I do find your ideas on line breaking intriguing. I too spend a fair amount of time on my parts settings up breaks the way I want, and would welcome any automation that was possible. I think the problem wouldn't be so much implementing an algorithm - it would be deciding on the algorithm to implement. I am somewhat familiar with TeX, so I do understand the terminology you are using regarding penalties and so forth. But I have have a strong sense that in the end, TeX could make any of a thousand choices and people would be happy, feeling little need to override things manually if it did an even half-way decent job. Whereas with music, I feel people would still want to tweak things, and it might prove just as hard to get the desired end result. That is, people are more inclined to want to micromanage music than text. But FWIW, I just finished a book using LaTeX - one you'll be hearing about here very soon :-) - and there were any number of places I found myself cursing its layout algorithms (both line breaks and page breaks).
I'd say if you want to help, maybe you could spend some time working through the algorithm in abstract terms (not worrying about C++ syntax). If you can get it concrete enough, then maybe someone would take on the challenge of implementing it. FWIW, the most important parameter you would have to work with it "minWidth" - the calculated minimum widths for each measure based on the current setting and the content of the measure. The current algorithm is, as you say, "greedy" it fills a system until the accumulated minWidths would be too large for the system width, then it takes any leftover space and stretches the measures proportionally.
As for collisions between markings, I am not so hopeless. Here, I think it is easier to describe algorithms that would produce "good enough" results. And one very important advantage would be, if it produces results you didn't like in some passage, you could reset the positions there and re-adjust manually without affecting anything else in the score. Ties and slurs specifically might be harder than markings more easily described in terms of their bounding boxes, admittedly.
In reply to Regarding the example from by Marc Sabatella
BTW, for the record, here is the default result of MuseScore 2 for the example from that blog post:
As you can see, much improved over 1.3, but there is no automatic offsetting of voice 3 relative to voice 1 in the places where they conflict. This would not be particularly difficult to implement, but the problem is, it isn't the right thing to do in all cases. Often, one uses voice 3 for reasons other than complex polyphony but rather to achieve certain alyout effects that *depend* on the voices align. My thinking has been, it's easier to manually offset notes that start out aligned than to manually align notes that start out offset. But anyhow, this too could be something where an explicit command could be run over a selection to add the necessary offsets for you.
In reply to BTW, for the record, here is by Marc Sabatella
I agree completely.
Yes, if this command existed it should operate only on a selection and not on the whole score.
For me, collision avoidance is a major issue. That's because I use MuseScore to prepare practice files for SATB choirs, and I don't want to spend hours manually adjusting the layout. For the source material, I usually use optical music recognition (SharpEye) to generate a MusicXML file. Then the MusicXML is imported into MuseScore. The example shows typical collisions.
Maybe I don't know enough about MuseScore yet, but using Style > Page > Stave Distance to create more space doesn't help to remove the collisions. I would welcome a batch algorithm which could do most of the work for me.
In reply to For me, collision avoidance by Dan Rootham
It mainly depend how good the MusicXML is, meaning where the hairpins and dynamics are attached in the MusicXML. But you could select everything, press Ctrl+R. Then change the space between staves, the default height of hairpins and dynamics. All in Style > General and Style > Text for dynamics.
In reply to It mainly depend how good the by [DELETED] 5
Perhaps I am being unfair to MuseScore, and the problem is that SharpEye is still exporting as MusicXML 1.0?
I can't judge whether the hairpins and dynamics are "well attached" in MusicXML terms. I am attaching the XML file generated by SharpEye in the hope that someone can tell me that MuseScore is already doing the best it can!
In reply to Perhaps I am being unfair to by Dan Rootham
It's likely that most OMR software will do a bad job of a *lot* of things that will require cleanup. It's just too inexact a science. OCR is easy in comparison - text is pretty much always a single linear list of characters - and when it isn't, most OCR software struggles to make sense of it.
Anyhow, shouldn't be needing to adjust most things one at a time. For example, if dynamics and lyrics are constantly colliding, that should tell you that the default positions for one or both of these elements types is not ideal. So, change the default. One common convention in vocal music is to position dynamics above the staff for exactly this reason. So, Style / Text / Dynamics, set a different default vertical position. Same with Style / General / Hairpins. If you want some above, some below according to voice, you can make that happen more globally as well. You can move groups of related elements together - right click one and use the Select menu to help select which you wish to move together, then use the Inspector. So, right click a voice 2 dynamic, Select / More / Same voice, then move them all together.
Not to say that some automatic collisions isn't valueable as well - it definitely is. But there is a lot you can do just with Style settings and other more global adjustments.
In reply to It's likely that most OMR by Marc Sabatella
@Marc
Thank you very much for the helpful hints: I still have a lot to learn about global positioning of dynamics and lyrics.