LilyPond Engraving Challenges
Urs Liska from the LilyPond project has initiated a set of "engraving challenges". The idea is to compare different notation programs to see how they fare trying to produce publishable music. The assumption is that LilyPond will produce the best results out of the box - relatively few manual tweaks required - but that WYSIWYG programs will make the process of performing those tweaks easier. The challenges are designed to test this theory and document the results. Here is the main site for the challenges:
https://github.com/openlilylib/engraving-challenges
I have volunteered to take up the challenge on behalf of MuseScore, which isn't to say others can't participate as well. Indeed, I don't know that I'll have the time to participate as fully as they might want. So far, there are two challenges open. Both are pages excerpted from Romantic-era solo piano pieces.
I've begun work on #2, which was added after I and a few others complained that #1 was too quirky (lots of highly unusual notations) to make a good starting point. I'm using the development (2.0) version of MuseScore, and I intend to use the experience to help improve MuseScore - submitting issues I find along the way.
Anyhow, feel free to check in the progress, or volunteer to participate yourself!
Comments
What's the actual point of the challenge? You can make scores in either look like an old engraving but I think music publishing has moved on a bit since the days when cramming nine measures in per line was the norm.
In reply to What's the actual point of by underquark
The goal is not necessarily to mimic the exact layout of the original - it's to see what's involved in producing one's own edition. It's not just about comparing the final results; it's about comparing notes on the process itself. We use GitHub to maintain our files, and we commit many versions of our score as we go as well as our own written notes on what we did. For instance, in my version, I committed 17 separate versions documenting my progress, starting with an empty score and ultimately leading to one that renders like this:
schumann.svg
This is the first one, so it's not really totally clear what will happen from here, but my assumption is, as more people complete it, we will comment on each others work, suggest improvements, and discuss the experience on the mailing list.
In reply to The goal is not necessarily by Marc Sabatella
OK, I get it now. Analysis of Effort:Result ratio is used in many disciplines, sales strategies etc. so if a particular task is common enough, takes many steps and can be simplified then that would be a good thing for both programs.
Like the positioning of dynamics - MS often puts them a bit too far right. I know steps are begin taken in 2.0 to improve this, but I see either MS2.0 or manual over-correction has placed the ff in measure 29 (at the tempo primo) too far to the left. Later on I see how the dynamic marking needs tweaked to go down a bit etc. I'd envisage a general algorithm to place the dynamic and then a simple corrective step such as right-click on it and choose from one of nine positions on a grid. The really tricky dynamics could still be further tweaked manually.
And I see that this score is a very good example of where multiple-selecting and then having the same action applied to all would be good (making the rests in the 2nd Voice invisible, moving the minims a smidge to the right etc.).
The ultimate trick would be to have the program analyse a particular measure, see what the user had done in the way of tweaks and then apply those same tweaks to another, selected measure.
I also now realise how time-consuming this really could be as opposed to just banging off a copy of a score. Good luck.
In reply to OK, I get it now. Analysis of by underquark
I totally missed the horizontal position issue on that "ff", thanks for pointing it out. That is a 2.0-ism. It seems the default works great for single character dynamics, but makes ff and pp a bit too far right, which will be noticeable at the beginning of the measure mostly. I guess that's why part of this issue is still open: #12488: Default dynamic positioning, but I'd say the 2.0 defaults are much better than 1.3. And with everything being easily keyboard nudgeable, the whole process of making manual adjustments is much smoother as well.
I did take good advantage of multiselect. For instance, the voice 2 rests were selected with right click, select / more / same voice + same staff. I didn't choose to move the LH half notes, but if I wanted to, I can't see any way around having to ctrl+click them individually. Here again, though, 2.0 offers a much improved workflow here in that Once I manage the multiselect, I can move them all right in real time with the Inspector.
I joined the challenge with MuseScore 1.3 - for the complex piano music it was not without lessons learnt: https://github.com/engraving-challenges/winterwind/tree/master/MuseScor…