"Smart" positioning

• Mar 30, 2015 - 22:03

At least one of our monstrously expensive rivals—the one that starts with an S—does something that I'm becoming surprised MuseScore 2.0 doesn't do. To wit, Sibelius has the excellent, excellent feature of simply making sure that its automatic positioning doesn't make elements overlap.

An example: put a few Bs on a treble staff (the middle line). Tie a couple of them together, and then put an accent (a regular sforzato) on the note that starts that tie. MuseScore just goes ahead and does this, with a result that doesn't look good at all. (I might be inclined to call this "dumb" layout.) But Sibelius automatically recognizes and avoids the situation of having the accent mark interfere with the tie. The accent is bumped up a space, actually to above the staff. No manual readjustment is necessary.

Another example: insert a first and/or second ending. Add some staff text. In MuseScore, these will literally be right on top of each other, making the text completely illegible and interfering with the line. But Sibelius will automatically move the preexisting line up a bit to make room for the text.

One final example: enter a note reasonably high above the staff, like a C or higher. Add a trill line to that note. MuseScore just plops the trill line at a predetermined spot, making an awful mess of it. Sibelius smartly adjusts and puts the trill line neatly above the note.

I'd like to recognize, though, that I've noticed at least one such case where 2.0's handling has improved over previous versions. I remember clearly that upbow and downbow markings formerly were handled the same bad way that trill lines still are. Now, they're an exemplary case of "smart" positioning: if the note is high, than the downbow will go higher.

I'd love to see this kind of thing done right in the next version of MuseScore. Given that this is a program dedicated to producing beautiful sheet music, I hope you'll agree.


Comments

It's definitely something we'd love to see long-term. It's a very complex set of calculations, though, and would require a lot of computing resources as well, given how we currently layout the entire score on every change. So it's not something easily retrofitted into the current source. I suspect we'll probably start small, looking for specific collisions that are considered especially likely or especially problematic, and then work out way from there to covering more cases over time.

Do you still have an unanswered question? Please log in first to post your question.