Amazing

• Jun 28, 2015 - 22:47

I've just completed a pair of very complex piano scores with MuseScore 2.0 that I have been unable to engrave satisfactorily with any other WYSIWYG music notation software. The results are beautiful. A huge thanks to the MuseScore team for making it possible.

I won't pretend it wasn't a lot of work. Scores of this nature demand an unholy amount of manual tweaking. That MuseScore could meet my every requirement speaks well for the foresight and careful coding that has gone into the program.

I've written a blog review of my experiences creating these scores (//missives-from-the-edge.blogspot.ca/2015/06/musescore-20-great-success.html ). It looks at various challenges I faced, and assesses how effectively MuseScore dealt with operations I had to perform repeatedly. A few were maddeningly time-consuming, and could, I believe, be improved for the benefit of everyone, not just composers who write difficult or unconventional scores. Most, however, receive top marks. As time permits, I'll file Feature Requests one-by-one based on the items in the article.

The blog contains links to both PDF versions of the scores and their counterparts (with playback) on YouTube.

Comments

• Jun 29, 2015 - 09:28

Thank you for the extensive review !

There is one points I don't understand well. Maybe you could elaborate with a short MSCZ example? or maybe you posted about it already?

I sometimes needed to change clefs mid-bar, but also needed courtesy clefs enabled, which do not permit mid-bar changes.
I don't understand. You probably don't mean the following since it works. What do you mean?
Capture d'écran 2015-06-29 10.19.19.png

Reply

• Jun 29, 2015 - 16:54

No, I did mean what your example shows, and yes, you're right, it works. I'll remove that item from the article. Because the whole bar changes colour when you drag a clef into it, just as with time signatures, I've always assumed it was a measure operation, not (optionally) a note operation. And somehow, in three years of using MuseScore, I've never "accidentally" dragged a clef over a note and seen it become highlighted. Possibly the reason is that if the dragged clef is directly over the note, one can't see the highlighting. It has to be slightly to the right. Regardless, thanks for correcting my misunderstanding.

Reply

• Jun 29, 2015 - 16:49

Yes, very nice writeup, and great job on the engraving and the music!

I think a couple of places you were maybe too charitable in your assessments (eg, open ended ties, continuing beams across system breaks are, I think, more serious limitations with more inconvenient workarounds than I would like). A couple of places it seems you might have just missed out on a feature that *is* there, however:

#13 - I am not sure I understand. Arer you saying you *wish* to have accidentals apply on the the that is following? That is indeed unusual but not unheard of. FWIW, you can define keyboard shortcuts for the various accidentals, so you aren't limited to just arrow up/down - you can apply accidentals directly via keyboard.

#14 - I don't understand this. Follow text works assuming your text reflects the time signature. If they don't agree, then indeed MuseScore might get confused. Not sure what you mean about notes appearing with no stem. It's possible you have a font conflict, perhaps from having previously installed an experimental nightly build or from installing an experimental early version of the oepn source Bravura font. This *does* normally work, and FWIW, the vertical positioning of the note glyph is improved in the upcoming 2.0.2 release. Feel free to start a new thread giving specifics on this, chances are it is something easliy straightened out.

#15 - MuseScore *does* support custom palettes - see the Handbook under that term. Also, don't drag to extend lines except for making fine adjustments. Shift+right click is needed. I think you know that already?

#16 - Actually, the keyboard arrow keys also work very well for repositioning dynamics. I also don't understand the comment about hairpin. The right endpoint is exactly as it is designed to be. I suppose it *could* have been designed differently, but I don't see a bug. The hairpin extends for the full duration of the selection, whether a single note or multiple notes are selected. It's consistent that way, and very convenient for the common case where you want the marking to extend exactly a full measure.

#17 - I do think a shortcut to add pedal marks will be coming some day as part of the accessibility work, and this should address your main concern. However, I do disagree about the most sensible defualt for pedal lines added by drag & drop. For "most" music over the course of history, pedal changes on average once a bar is quite appropriate more often than any other single default you could come up with.

Other comments:

- So far, all evidence is that the PDF output is fine - it displays and prints beuatifully using any other software. The issue clearly seems to be that Okular for whatever reason showing you some anti-aliasing artifacts that would presumably be fixed if you changed its settings (assuming it provides such settings).

- The bug with Respell not being preserved on save/reload is already fixed.

Reply

• Jun 29, 2015 - 23:46

#13 - I am not sure I understand. Arer you saying you *wish* to have accidentals apply on the the that is following? That is indeed unusual but not unheard of. FWIW, you can define keyboard shortcuts for the various accidentals, so you aren't limited to just arrow up/down - you can apply accidentals directly via keyboard.

Yes, I wish to have accidentals apply only to the notes they precede (for music that has the direction "Accidentals apply only to the notes they precede,") as opposed to accidentals carrying throughout the whole bar. It's a specific-case scenario that doesn't occur in music before the 20th century. In music that treats all 12 tones equally, every pitch needs to be specified since key signatures are meaningless, and seeing whether a note with no visible accidental had an accidental applied to it earlier in the bar, one that should be applied to the non-accidentaled note, is a score-reading nightmare. One solution, used by Schoenberg, was to precede every note with an accidental, including natural signs. The thicket of accidentals this creates makes reading the score difficult, especially at sight. The better solution, widely adopted, is to omit all natural signs, such that any note without an accidental is construed as natural. For score engraving software, this means having a way to tell the program, for the purposes of playback, that any note not preceded by an accidental is to be construed as natural.

#15 - MuseScore *does* support custom palettes - see the Handbook under that term.

I'm aware of custom palettes. What I can't do is create a "Rit....." type line to add to my custom palette, i.e. the word "Rit." followed by a dashed line flush with the baseline of the text, ending with a downward hook. I've followed the instructions in the manual to the best of my understanding. If you've time, could you walk me through this, assuming it's possible? If nothing else, it may reveal places where the manual needs to be worded differently.

#16 - ...don't understand the comment about hairpin. The right endpoint is exactly as it is designed to be. I suppose it *could* have been designed differently, but I don't see a bug. The hairpin extends for the full duration of the selection...

For me, the problem is with "full duration", which includes through the last note of the selecction. Consider this example:
hairpin.png
The first bar shows the default right point under very simplistic circumstances, where it's acceptable. The second bar shows where the default behaviour falls down. I selected the first and second half notes, wanting a diminuendo to be executed during the first half of the bar, between the half notes. What I get is a diminuendo that extends through the whole bar. Not only is that incorrect visually, it also produces incorrect playback unless I specify that the hairpin applies to Staff, not Part, which in turn means that if I want it to apply to both, I have to add a second hairpin, hidden, to the bass clef, and assign both to their respective staves.

Concerning PDF as viewed in Okular, it remains a significant problem. With text and graphics anti-aliasing enabled, and the option to enhance thin lines set, the output is still terrible.
pdf-screenshot.png
It's marginally better with Evince, but still not as smooth as every other PDF file with diagonals and curves I have ever opened or created. Only the 'katarat' and 'mupdf' viewers render MuseScore PDF properly, but neither of them is even close to full-featured and therefore not likely to be widely-used on GNU/Linux systems.

Given the logic of the problem—all pdfs render properly in Okular except MuseScore pdfs AND MuseScore pdfs render properly everywhere except in Okular—it's impossible to state which is at fault, MuseScore or Okular. However, since the problem affects only MuseScore users, it would seem prudent for the MuseScore team to get to the bottom of it, regardless of where the fault lies. Meantime, "export to png and convert to pdf" is the only way I've found to ensure proper rendering of my scores in Okular. (Which begs the question: if the "from png" pdfs render curves and diagonals correctly in Okular, why doesn't MuseScore's native pdf code?) At any rate, with Adobe having recently announced they're dropping GNU/Linux support for Acrobat, it's even more important that Okular and MuseScore worki in harmony.

Attachment Size
hairpin.png 37.78 KB
pdf-screenshot.png 16.56 KB

Reply

• Jun 30, 2015 - 01:03

#15 - maybe it would help if you say exactly at what step something goes wrong. For me simply following the instructions in the handbook works fine. I create the line exactly how you describe you want it to look, I ctrl+shift+drag it to my palette, it appears in the palette just as I created it, and when I then add the line to my score, that also appears exactly as the original. Are you having trouble creating the line in the first place, or adding it to your palette, or adding it to your score from the palette? If you say which part is giving you trouble, I can be more specific about how I am doing that part.

#16 - I still don't understand. if you don't want the crescendo to extend the duration of the second half note, simply don't select the second half note. Select only the first and you get exactly what I think you said you wanted. Again, the crescendo is consistent in that it always lasts the full duration of your selection. There is no bug I can see - it seems you simply are making the wrong selection for what you are trying to do. If you only want the crescendo over the first half of the measure, then only select the first half of the measure.

Regarding Okular, since it looks fine in every other viewer and every printer, it still seems extremely likely the problem is with Okular. Just because they happen to be able to handle some other PDF's fine doens't mean there isn't an issue that causes them to do badly in this case. Have you tried contacting them?

Even if it does turn out the problem is something wrong in our PDF that everyone else manages to handle well even though it is technically incorrectly, they would be in a much better position to determine this than we, since they presumably have more exterise in the subtle details of PDF rendering than we do. For the record, we use the same basic Qt rendering primitives for PDF, PNG, physical printing, and on-screen display; we really do not have a ton of control over how any of this works. But if they tell us that setting some flag or other within Qt would make their software happier, and it doesn't break anything else, we could certainly look into it.

Reply

• Jun 30, 2015 - 03:32

...create the line exactly how you describe you want it to look, I ctrl+shift+drag it to my palette...

Aha! That's the problem. I can't find any mention of Ctrl+Shift+drag for adding items to a palette under any of these headings in the manual (pdf version): Palette->To edit a palette, Advanced topics->Custom palette, or Advanced Topics->Workspace. Can't find it anywhere in the manual doing a text search, either. I'm thinking an oversight? At any rate, if it's there somewhere, it needs to be reiterated in the section on adding items to the palette.

I still don't understand. if you don't want the crescendo to extend the duration of the second half note, simply don't select the second half note. Select only the first and you get exactly what I think you said you wanted. Again, the crescendo is consistent in that it always lasts the full duration of your selection. There is no bug I can see - it seems you simply are making the wrong selection for what you are trying to do. If you only want the crescendo over the first half of the measure, then only select the first half of the measure.

Guess I'm not making myself clear. I thought the example would be enough to extrapolate the problem generally, but your response deals only with the specifics of the example, i.e. a crescendo over the first half of the measure. Here's a step-by-step better demonstration of why I think MuseScore's got it wrong. We start with this:
01-plain.png
Now, we want to add "p" to the first quarter note, "f" to the third, and a cresc. hairpin between them. Approaching this methodically and logically, we begin by selecting the first quarter.
02-A-selected.png
and adding the "p".
03-p-added.png
Next, we select the third quarter
04-2nd-A-selected.png
and add the "f".
05-f-added.png
So far, so good, and very sensible. Now, we select the two notes between which we want a crescendo hairpin
06-2-As-selected.png
and hit "<".
07-hairpin-added.png
The leftpoint position needing to be shifted is to be expected because of the "p", but the long continuation of the hairpin through and past the "f" is clearly not what we intended. Except when we want to crescendo through a note (which MuseScore playback can't do, anyway), the correct place for a hairpin to stop is at the start of the beat, not the end. A quick check of some C. F. Peters Edition scores shows that hairpins never extend past the right of the notehead corresponding to the beat where they are expected to end.

The solution, of course, is to select the note to the left of the one where we want the hairpin to end, but this is not intuitive.

The other concern I have with hairpins is their left alignment with accidentals. This small example shows how this results in hairpins that don't align flush left.
08-misaligned.png
Not a huge issue for something this simple, but multiply that by all the staves in an orchestral score, and you can see how much manual tweaking would be required to get the hairpins aligned for every instrument. Surely the better place to begin hairpins is flush with the notehead, not the accidentals?

Attachment Size
01-plain.png 4.72 KB
02-A-selected.png 12.74 KB
03-p-added.png 13.09 KB
04-2nd-A-selected.png 13.11 KB
05-f-added.png 5 KB
06-2-As-selected.png 13.63 KB
07-hairpin-added.png 5.49 KB
08-misaligned.png 10.2 KB

Reply

• Jun 30, 2015 - 03:41

"Except when we want to crescendo through a note (which MuseScore playback can't do, anyway), the correct place for a hairpin to stop is at the start of the beat, not the end."

Here's why that doesn't work. Select a single note (say it's a whole note—an entire measure) and press <. Should the hairpin start at the beginning of the note, and end at the beginning of the note (i.e., not be there at all)? I think not. It should, in fact, be added to the note, and extend over the length of the note. Anything else would make no sense.

Reply

• Jun 30, 2015 - 05:02

Once again, I didn't express myself clearly. That should say: "...the correct place for a hairpin to stop is at the start of the beat of the last note of a selected range". It should not extend visually through the value of that last note. Honestly, I can't find a single example in my library where such a convention is used.

MuseScore's handling of the "single note" < of your example is fine: the hairpin has to end somewhere. As a user, I'd expect the default (through the note's value, but that could just as easily be "to the end of the bar" or some other necessary default) to occasionally not be what I wanted, and wouldn't give it another thought. But when the default for a range of selected notes always does the wrong thing, based on reasonable expectations derived from familiarity with the rest of the program, then, IMHO, it's an impediment.

Reply

• Jun 30, 2015 - 17:27

There is a bit of a disconnect in our use models here.

I always think about selecting a *range* when applying a hairpin, not selecting *end points*.

If I think in terms of selecting a range, the semantics seem clear to me: I want the crescendo to apply throughout this entire range. That is, I don't stop getting louder until I reach the next note. This is most clear if my range consists of a single note only - I want to crescendo for the duration of the note. Obviously, not possible on piano or other percussion instruments, but quite meaningful for most other instruments. And the same principle applies if I select a range of two or more notes - I want to crescendo for the entire duration of those two notes.

Because you have been selecting *end points* rather than "ranges", you have a different mental model - you are expecting to crescendo *from the first note and then up to but not including the second". That's logical enough - it's just that, as I mentioned, it doens't actually work correctly (you get two overlapping hairpins), and as of right now, is simply disabled in the nightly builds that will become 2.0.2.

So I think if you simply adjust your thinking to *ranges* instead of *end points*, you will find the current behavior perfectly natural, and what's more, it works correctly, unlike the method of selecting end points.

However, you've given me food for thought. *If* we decide to support selecting end points rather than ranges before applying the hairpin, maybe we should treat it differently than we treat ranges. One thing that strikes me as a little odd about that idea: it means you'd get different results if you click one note then *ctrl* click another (thus selecting end points) versus if you click one note then *shift* click another (thus selecting a range). Maybe that's OK.

Reply

• Jun 30, 2015 - 18:31

Marc, thank you so much for this clarification. It explains everything, and clears up the whole matter. Face to face, this would have taken about two seconds, but such is the nature of forums. I have to say that you and the others who post here regularly in response to user questions etc. must have the patience of Job. I applaud you.

Reply

• Jul 1, 2015 - 19:38

Thanks to you as well, for your thoroughness and willingness to discuss these issues. To me, the possibility for this sort of exchange is in itself one of the truly wonderful things about open source software and MuseScore in particular!

Meanwhile, we have been continuing to think about the these ideas, and hope to have some good news to share soon :-)

Reply

• Jun 30, 2015 - 05:09

Re: custom palettes - I guess you grabbed a PDF copy of the Handbook before that bit was added.

Re: hairpins: your mistake is selecting the first and third quarter notes. For one thing, selecting two separate notes doesn't actually work correctly in the released version. You don't get a single hairpin, you get two overlapping ones. This is fixed for 2.0.2, but you'll find selecting two separate notes first isn't supported. The correct way - in both 2.0.1 and in 2.0.2 - is to select the *range* of notes you want the crescendo to apply to. So in this case, you select the range up to *but not including* the quarter note on beat 3. You then get exactly what you want. The note on beat 3 is not part of the selection, so the hairpin stops short of that note.

Regarding alignment relative to accidentals - you are absolutely correct; please file a bug report and I'll look at fixing this.

Reply

• Jun 30, 2015 - 01:51

BTW, there are existing feature requests for one-sided ties (see for instance #22010: Playback of tie for non adjacent notes (repeats)), and existing bug reports for the cross-system beaming (#16278: Beaming notes over barlines and line breaks), and as you've seen the issues with 16th notes in tempo marking and "follow text" and horizontal cross-staff beams are already filed for you and also already fixed :-).

If you are still seeing *display* issues with tempo markings - aside form the vertical alignment, which as I mentioned is already fixed as well - do explain in more detail. But I suspect it will turn out to be a font installation issue.

I don't see an existing feature request for the "accidentals apply only to one note" mode, so do be sure to file that. I agree, it's worth supporting directly.

Also, regarding slurs - here again I think you are being more charitable than I would, as there are any numbers of times I need to adjust slurs because they collide with stems. I probably spend more time adjusting slurs than any other single manual adjustment. However, I don't understand your comment about slurring a downstem note to an upstem note. I just tried duplicating the example toward the bottom of p. 111 of Elaine Gould's "Behind Bars", and we do it virtually exactly how she shows: starting just above the notehead of the downstem note, ending not quite at the end of the stem for the upstem note so as to get the proper tilt, just as she recommends. But it's possible you have a different specific scenario in mind, or perhaps different expectations.

And thanks again for the detailed writeup, and congratulations on the beautiful work (listening to "Kun" right now)!

Reply

• Jul 3, 2015 - 20:48

As I hinted earlier, I have good news for you. Actually, good news and *better* news - which would you like to hear first? :-)

The good news: we went ahead and fixed hairpins to work as you expect if you select a start and end note instead of a range. As I had mentioned, this didn't really work correctly in 2.0 or 2.0.1 - with N notes selected, you got N hairpins, all overlapping. We had tentatively fixed this for 2.0.2 by *disabling* adding a hairpin with two or more note individual notes selected - we were going to require a range selection or a single note. But as of the next build, if you select exactly two notes on the same staff, you will get you expected in the first place: a single hairpin that ends *before* the second note. Behavior with ranges will remain unchanged - the hairpin will extend *through* the end of the range.

The better news: at the same time, we made it possible to add *any* line by selecting a range, or the two end points, and then double-clicking the palette icon. Meaning, you can add a pedal marking precisely by selecting where you want it to apply and double clicking the icon - no further adjustment required. This will also work for ottava, voltas, trills, text lines, etc.

We're still tweaking things further, and as I mentioned, this is all part of a larger effort to make the UI more accessible to people with disabilities that make using the mouse difficult or impossible. Eventually, we want the palette to be usable with keyboard only, but getting it work on a selection with double-click rather than requiring drag & drop + manual adjustment was a very important first step. So thanks for providing the impetus for us to start moving forward on all this!

Reply

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