MuseScore 3.5 engraving report

• Jul 1, 2020 - 10:10

(If you're wondering what this is all about, see this post!)

Background

My engraving experience started around 1995 with Acorn RISC OS Sibelius; shortly after that I started working professionally for Boosey & Hawkes, and the experience of doing my first score in Sibelius convinced me that it was not really suitable for publication-quality work at that level (not that this stopped many publishers at the time!); shortly thereafter I switched over to using SCORE, the quality of the output of which had long been an inspiration to me, and I used it ever since.

The strength of SCORE lies in its flexibility; you can change (almost) any aspect of the notation in whatever way you like, even if it results in something that makes no musical sense. This is completely invaluable for handling any kind of unusual or advanced notation. I have often characterised SCORE as a graphics program that happens to know a bit about music; it does not force you into working a certain way.

The downside is that nothing is automatic; if you move a beam the length of the stems underneath does not change (unless you tell them to); conversely, if you change the stem length of a beamed note, the beam does not adjust automatically. Working in SCORE is very 'low level'; like programming in C as oppposed to something like Python. Nevertheless, its flexibility and power (and extensibility: the simple file format and modelling of data mean that it's very easy to write tools to help with all kinds of tasks; some users have written very powerful tools which act as extensions of the program. I've even written a few myself.) And the possible quality of its graphical output is why it is still used extensively today.

In the past few months I started using Dorico, having had a copy sitting around for a couple of years. It is a totally different experience from SCORE; for one thing, it can function as a composition/arranging/playback tool (SCORE is really an engraving tool only, concerned with the visual appearance of a printed page and nothing else). I used it for making some quick arrangements of music, transpositions of some songs, and a score of a chamber piece from a set of parts. All of these things would have been rather painful and arduous in SCORE, though they are possible.

Dorico, unlike SCORE, does a lot of things for the user, and in particular I was impressed by the lengths it goes to ensure that after basic input, the music is grammatically and graphically correct. That is to say, rhythmic groupings and beaming is right, accidentals including cautionary accidentals are automatically and logically applied (grammar), and items are well spaced, positioned, and collisions are avoided (graphics). This is essential given that the average user often does not know about the rules of notation, or possibly is more interested in actually getting stuff on paper and doesn't care about them; moreover, in my experience as a performer playing in countless composer workshops at universities and music colleges, even otherwise talented and knowledgeable composers have no idea about the subtleties of notation (or the practical importance of getting the details right), and assume that whatever the computer has produced for them automatically will be perfectly adequate.

The holy grail of notation software is that after basic input of all the notes and other items, the resulting score will automatically look perfect with no extra tweaking required (according to built-in and extensively user-customisable preferences). Currently no notation software does this - and SCORE doesn't do it at all, requiring huge amounts of time and expertise, but repaying it handsomely - but Dorico already does a very good job in most situations. There is no reason why MuseScore cannot do just as well - or better.

In assessing the current state of the engraving quality of MuseScore 3.5, I was looking at it from several angles, including:

  • How good is the default appearance of music when input? What problems are apparent and how easily can these be fixed manually?
    • When making adjustments, how flexible and powerful are the options? Are there things that cannot be done without painful workarounds?
    • What would be lacking in MuseScore for a user wanting to produce a score professionally for publication by a 'major' publisher?

This report represents a first look at these questions but does not pretend to be exhaustive. A thorough exploration of any of these questions could continue indefinitely, and in any case would be a question of long-term gradual development. The aim was to identify the most important general areas that could then be prioritised.

Process

I spent three days using MuseScore to engrave three different types of score, to assess the strengths and limitations of the engraving currently. This was also my first time using the software, so learning how everything is implemented from a UI point of view was part of this experience.

For each day I wrote up a general report of my findings. The three scores were:

  1. A page from Harrison Birtwistle's choral/orchestral work Angel Fighter, which I engraved in SCORE in 2009/2010 for Boosey and Hawkes. Here, as well as being my first exposure to the program, the aim was to see to what extent I could replicate the style and quality of a score I had made myself, without unreasonable amounts of effort. Report: (link to follow)
  2. A page of reasonably dense and elaborate solo piano music, in this case part of a cadenza from Medtner's Piano Concerto No 2. The engraving challenge posed by dense, multi-part music on two staves is very different from that of single lines, even when there are many of them, as in an orchestral work. This also provided the challenge of matching the quality of (good) old-school plate engraving. Report: (link to follow)
  3. A very dense page of orchestral music, taken from Strauss' opera Daphne. Here the aim primarily is to assess the suitability of MuseScore for handling scores with large numbers of instruments, and the some of the layout problems this throws up - so matters of page layout and scaffolding, alignment of items between staves, instrument handling and so on. Report: (link to follow)

I'd encourage reference to those reports for information on some of the details I found and thoughts I had on the way.

Findings and recommendations

First impressions are important, and when it comes to prioritising issues to tackle, it makes sense to start with those that will make the most immediate impact - especially where the cost of implementation is low. In general this means looking at aspects which affect the layout or overall appearance of the page, or changes which affect the majority of notation items, before worrying about fine graphical details within the music itself. The following list broadly follows this, so can be taken as a first attempt at prioritising the issues that need attention.

Fonts

Some people are no doubt fond of the default music font, Emmentaler. I don't think it's hideous, but it's problematic in quite a few ways. I certainly wouldn't to get rid of it but I think having a better default music font is the easiest single stem to improve the quality of the output. (Conversely, a bad basic symbol set immediately marks a score out as 'amateurish' - even if it's anything but.) Two strategies have been discussed in the design team already:

  1. Switching to Bravura as the default, possibly as soon as for the release of 3.5. Steinberg have done a very good job with it (I certainly don't agree with 100% of everything but it's better than any currently available OFL alternative). Some users wont like this - musicians tend to be conservative and object to changes generally, but they can change back to Emmentaler if they really want to. Many, I suspect, don't actually think about the font at all, or particularly care. This effectively gives all new scores a free visual upgrade for almost no effort. Also a new font in v3.5 will perhaps ease the transition towards all of the visual improvements that will come in v4. The community has previously discussed this idea of switching to Bravura and rejected it, not wanting MuseScore to look too much like Dorico. While I take the point, I'd rather the scores just looked better, and Bravura is better.
  2. Develop our own font for MuseScore 4 (possibly to be the default), based on the SCORE symbol set. @Tantacrul and I have started work on this already. Scorlatti, by Abraham Lee, is an extant font which is a fairly straight conversion of the SCORE symbols, with a few alterations of his own. I'd propose we do the same thing ourselves. I have my own version of the SCORE symbol set to which I've spent a lot of time over the years making small refinements (for the most part nuances of placement, consistency, positioning) which collectively - in my own humble opinion at least - add up to a significant improvement over the defaults. Having our own font also moves us away from being a 'Dorico clone'. (We don't want to be a SCORE clone either!)

A surprising number of text items are used on a music page: not just titling and instrument labels and tempo markings, but also within the music itself: expression and technical instructions of course, but also e.g. tuplet numbers and fingerings. Therefore changing the text font will also have a big impact on the page. FreeSerif, the current default, is not a beautiful font, and as a Times New Roman analogue, unimaginative too. (From Wikipedia: "Monotype executive Stanley Morison, who commissioned Times New Roman, noted that he hoped that it "has the merit of not looking as if it had been designed by somebody in particular"".) Fonts with a bit more weight tend to work well with music notation; Boosey's default is New Century Schoolbook which works very well (and it's no surprise that the Dorico team chose to do a very good impression of it with Academico); Chronicle Text is an example of a commercial font that would look good. Though we are, of course, limited to free fonts with an appropriate licence, or that we own outright.

Different music fonts will work with different text fonts; so some time could be spent finding good pairings. This can form part of the work on styles.

Styles

Many - even most - engraving questions have no single answer. Often the answer is 'it depends'; just as often, when asked about whether option a or b is better, the answer is "pick either one, it doesn't matter - just be consistent". It is no surprise that managing styles and preferences in music notation software is complicated; this is something else that Dorico has done quite well. (SCORE doesn't help you at all: you just need to be extremely disciplined. But this buys you the ability to easily break free of a style rule in an exceptional case if you need to.) Furthermore, there are differences in style between genres (baroque, classical, romantic, jazz, pop) and even regions (there are distinct features of engraving style in France, Germany, Russia, the UK, the US, etc). MuseScore 4 should, at the very least, provide a number of default preset styles for different types/genres of scores which will ensure elegant and consistent results with little or no further user intervention. This will cover everything from text and music font via bar number placement down to the policy on accidentals and tied notes.

The appearance of default scores could already be improved through overhauling the settings already available in the Style window. Some of the basic offsets are too generous, for example (dynamics and various text items). In conjunction with a change of default font and refining of some text styles, this could make a big difference. Also line thicknesses is an often-overlooked aspect of visual style: different settings will be appropriate for different music fonts, for one thing.

Page layout

The perception of the overall appearance of a page - before we even start thinking about the details of the notation - depends on a number of things.

Staves: size and vertical justification

A newly created score should have an appropriate stave size. These can be pre-set in templates, but if the user selects their own instruments, it would be very nice if a sensible stave size could be suggested for the number of staves involved. That is, if there are a lot of instruments, the stave size should at least be small enough that all the staves can fit; if it's a piano quintet score, it should be possible to get three systems on a page, and so on.

Vertical justification of staves is important. A page should be vertically filled, with the space distributed between staves/systems dynamically. MuseScore has most of the functionality for this already but it could be developed. In particular it needs to be possible to set maximum distances between pairs of staves (e.g. between left and right hand for piano, so they do not stretch too far apart) as well as staves that should have greater spaces (e.g. between instrumental sections in an orchestral score). Our templates would include sensible settings for this. SCORE has quite a good system that I propose I write up to see what can be taken from it.

The pages of a score are ideally formatted such that there is a music block (from the bottom stave line of the lowest stave to the uppermost stave line of the highest) on each page with consistent height and positioning. Exceptions to this should be possible in extreme cases.

I can even imagine a system whereby a template is dynamically generated based on the instruments chosen, the page size, font choices, and maybe other stylistic choices (period, genre, etc). But that's a project.

Instruments: labels, brackets and braces

The lack of automatic bracketing, bracing and barlines through systems is very problematic. This produces a very unprofessional appearance. If we steer the user more towards the templates, where these can be preset, so much the better (again, exactly how bracketing is handled is a stylistic choice to some extent), but where they define their own score by choosing instruments, sensible defaults should be applied. I also think that enforcing a default score order is important: at the moment the instruments are added in whatever order they are chosen, which can result in chaos. The user should not need to know all the details of how to order things conventionally; though they should have the ability to go against the standard if they need to.

Instrument labelling needs an overhaul. This is a complex area which will require a lot of configurability; at the very least, it needs to be possible to split labels into instrument names and numbering. That is, rather than Flute 1 / Flute 2 / Flute 3, we have three staves (bracketed) numbered 1 / 2 / 3, and a single 'Flute' label on the middle stave. As with all these 'page scaffolding' issues, there is a lot of variation here depending on style, publisher, country and so on. Much thought will need to be given for how to handle instruments combining onto a single stave or splitting onto multiple staves during the course of a piece, if that functionality is eventually desired (which it presumably is).

System text

Currently appears only at the top of a system. This will need to appear above the strings as well in an orchestral score, for example (this can also be set in templates), but in general it needs to be possible to have it appear at multiple positions as the tradition/user expects.

System indentation

The initial system of a piece, or a movement, should be automatically indented, even when there are no instrument labels. Not doing this is another 'amateur' giveaway.

Horizontal spacing

Spacing and justification of music is one of the biggest challenges in notation. MuseScore does a good job currently, but much better is possible. In particular, spacing requirements on one stave should not affect the spacing on other staves where it is not necessary.

The spacing abilities of SCORE are renowned. Some of how it works is documented, some other aspects I know from experience, and some more I could deduce through experimentation. I would propose to write up its method as best I can, to assess the feasibility of incorporating it into MuseScore. As well as producing an excellent visual result it is also extremely configurable.

(Despite the brevity of this section, this is definitely a major undertaking.)

Beaming and stem lengths

This is an challenging area where MuseScore does not do particularly well. The community (on Telegram) have also drawn my attention to this already and say that the code is in need of an overhaul, both for readability as well as its functionality. Beam placement is an art rather than a science, and there are different views on what rules to follow. Moreover, as with horizontal spacing, there needs to be a lot of user customisability. However, it is easier to break down into a system of rules. Like the horizontal spacing question, this is a big task, but will make a correspondingly large impact on the visual appearance of scores.

(The handling of tuplet brackets is also closely connected to the question of beams.)

Slurs and ties

Along with beams, the most challenging aspect of notation. There is much that can be improved here (several details I mention in my reports, but not everything). This is actually an area I have some coding experience in as I wrote a quite elaborate script (in Python) to automate positioning of slurs and ties in SCORE. This was not a one-stop solution - manual adjustment was still required afterwards, to some extent - but saved a huge amount of time as well as producing much more consistent results.

The two central problems with slurs and ties are endpoint placement and curvature. The endpoints should avoid colliding with other things (stave lines in particular, but of course notes, dots, other slurs and ties and so on), while remaining clear which notes they connect; curvature of ties should be relatively shallow, though proportional to their length, and the midpoint should also avoid stave lines; curvature of slurs should be sufficient to clear all items they span, though (unhelpfully) with some exceptions. Of the common notational items this is perhaps the most context-dependent. And, as with beams, there are many user preferences to accommodate.

Some good work has been done so far with MuseScore in this area, but a more more thorough specification of rules and robust behaviour is needed.

Notation features

Changing the music font can improve the majority of symbols on the page; staves, brackets and barlines, beams, stems, slurs and ties, which are all drawn around the font symbols, represent the vast majority of everything else on the page. Once the handling of those elements has been improved (and the related matters of spacing and layout), we are down to more localised notation issues. I have already identified some which I think are important to add in order to enable 'publication quality' work. Though I am still a new MuseScore user so there may already be solutions to some of these problems - and there will certainly be others that I have not yet discovered. These are essentially feature requests rather than an assessment of the implementation quality of currently available functionality. And this is nothing like an exhaustive list, just some things that occurred to me in the first few days!

Attachment of items to free rhythmic positions

It should be possible to attach items to any rhythmic position even if there are no actual notes (or rests) at this positions. This example from the Strauss for example:

attachment to rhythmic positions - small.png

On the lower stave, the cresc. should be locked to the second crotchet beat, not attached to the dotted minim and offset, such that it might move around if things are respaced, or parts extracted. This is very commonly required. It should not be necessary to use invisible notes or similar workarounds, which would distort the natural spacing if this appears in a different context (again e.g. when parts are extracted).

Here is another example:

attachment to rhythmic positions 2 - small.png

The right end of the triplet bracket should be positioned where the third quaver would go. (If there is a third triplet quaver in another part at the same time, it should be clear that it aligns with that. That also means more space will be required.) This means that MuseScore needs some way to determine the position of items that would exist at a certain rhythmic position, without having those items actually affect the spacing in any way.

How to implement a UI for this feature might be an interesting challenge! The simplest method I can imagine is adding the possibility to apply a rhythmic offset to a note, as opposed to (or in addition to) a visual displacement. So in the cresc. example above, the text could be added on the downbeat, and then given a rhythmic offset of +1 crotchet.

Accidentals and auxiliary notes for ornaments

It seems to be impossible to add accidentals to ornaments (frequently required for trills in all music) without painful hacks; this also has implications for playback. There is no mechanism for adding auxiliary notes (bracketed noteheads) either. This is a serious omission.

Grace note handling

I noticed various difficulties with grace notes:

  • Items cannot be attached to them
  • It is difficult or impossible to add/remote the slash
  • Clef changes cannot occur within grace note groups, nor between the grace note(s) and main note
  • The 'grace note after' and 'grace note before' options have confusing behaviours (I probably just have to experiment more)
  • Cross-stave grace note groups cannot have the beam between the staves

So this is an area which maybe could use some attention.

Intelligent text handling

There are some things I would love to see here - they are possible manually but are tedious, and I also know from long experience that handling all the text items around music can take up a surprising amount of time.

  • The ability to centre text on a note. Already we can centre text on its origin position, and left/right justify, but a marking on a note (arco, ten., div., and so on) looks best centred on the midpoint of the notehead, and with the end punctuation not included in the calculation. This is precisely how lyrics already work, so the functionality is there already! Perhaps a 'centre on notehead' option might be added to the already available options, but one which behaves intelligently (i.e. the extent to which the text is offset to the left can have a maximum limit, and also it can be graphically aware so that text is not pushed backwards into barlines, and so on.)
  • Intelligent 'stretchy' dotted lines for cresc. - - - and rall. - - - and similar. Again, lyric dashes already do this, so there is extant functionality that can be used elsewhere.

Some miscellaneous thoughts

The existence of the corpus of scores on musescore.com is extremely useful, as it gives us a huge body of data to test any general changes we make to determine shortcomings, find edge cases we haven't considered, or even to alert us that we're going down the wrong road entirely.

All of the above represents a (very ambitious) 'Phase 1'. A theoretical phase 2 involves drilling down into the really fine details of notation and working out optimal ways of handling them so that our solutions are as comprehensive as possible. Eventually that could get us to a place where a user who just doesn't care about any details don't have to - the notation will all look great by default, with no extra intervention.


Comments

Thanks for this! Very much looking forward to getting into the details as the time becomes right. A few comments for now:

  • I haven't seen the first example yet, but consider also using some not dense pieces as examples. One thing we struggle with is finding good defaults that work as well for complex as well as simpler scores. Also try examples from other genres - be aware that classical music is not necessarily what the majority of users are interested in.

  • As discussed elsewhere, my main reservation with to switching to Bravura for 3.5 as the default is practical: it is difficult to make it so older scores aren't affected adversely, and even for new scores, many existing users have existing scores they will want consistency with. I would suggest if the change is made, we find a way to make it (much) easier to set the default back; the current process is way too convoluted and hard to discover.

  • Also as noted elsewhere, indenting by default is fine in those genres where it is appropriate, not so much in others. So somehow this needs to be controlled by style and set in templates etc. Perhaps we need something more general than templates, a generic "classical" vs "jazz" vs "pop" set of style defaults to select between when creating a new score other than from a template.

  • Letting staff sizes and distances float is an idea that gets a fair amount of discussion here, so we have some ideas about what might be involved in implementing it. A stumbling block is deciding on how one would actually go about saying to what extent you want the program to increase staff size versus staff distance versus system distance (when the are multiple systems on a page). I think once a really clear design is put forth for this, implementation would be pretty straightforward.

  • Having system text (also voltas) appear on multiple staves is also something discussed for long, with some ideas on how it might work internally (it shouldn't be hard). The holdup is, again, designing how the user would specify this. My only experience is Finale's "staff lists", which got the job done, but were cumbersome to me. I would say, make it a staff property "display system text", but there is a bit more to it, as the "honor" should fall to the next staff below on systems where this staff is hidden.

  • FYI, accidentals can be attached to ornaments that are "Lines", not ones on the Ornaments palette, but they don't affect playback. Also, with respect to grace notes, articulations and some other things can be attached, but not text, if that's what you had in mind. Stem slashes can easily be hidden, but they can't be added. Way more flexibility in grace note handling would be nice indeed (also for playback).

  • Centering text on the noteheads should be trivial to implement.

  • Most of the rest is easy enough to see what needs to be done, but will require work :-)

Oh, I forgot one important thing, regarding horizontal spacing. I think you're right that it's "mostly" pretty good, but I've been made aware through discussions here and elsewhere of one major shortcoming - the degree to which things like accidentals or dots or ledger lines affect spacing unnecessarily. I've always been aware this happened, but not appreciated how problematic it can actually be, leading to uneven spacing from measure to measure. Also, due to the way measures are "stretched" to fill the system, there are even cases where you can get uneven spacing of the same note value from measure to measure without there being other symbols to blame, but just falling to how we allocate space according to note durations.

As with some of the other issues you bring up here, there has been some discussion and some understanding of what is going on and how it might be improved, but what we've been lacking is the clear sense of direction and design on this. So I'm definitely hoping for good things!

BTW, some historical notes that you might be interested to know:

Originally, MuseScore didn't have "automatic placement" and scores just had symbols colliding all over the place. We tried to mitigate this where possibly by setting style defaults that would have things stay out of each others' way naturally without any special collision detecting or avoidance. That is to some extent why you see odd style defaults that appear to create too much space - it was being conservative to avoid collisions with notes above the staff (for instance) and were never optimized as well as they could be once automatic placement came into the picture for MuseScore 3.

Also, one of the reasons for automatic placement - our first big step towards the "holy grail" of completely perfect engraving out of the box - was the desire for at least "pretty good" engraving within the mobile apps (iOS, Android) as you changed the scaling, transposed, hid instruments, or otherwise mucked with settings that could radically alter the layout. In other words, perfecting the printed page wasn't necessarily the main motivator. I guess if we ever achieved that holy grail, the mobile problem would take care of itself, but it's worth considering that there may be cases where certain half-steps might be more beneficial to that mobile case than to the use case of producing a printed page. So it would be good to consider both.

Thank you so much for researching and compiling this report, and to all at Musescore for commissioning it. It's been extremely helpful in understanding the capabilities and limits of Musescore, and why, from a user's point of view, some things just don't seem to work in the way one would wish.

I wholeheartedly agree with your comment about vertical justification of staves, and enhanced labelling and bracketing of orchestral instruments. It's baffling that Musescore doesn't anchor the top and bottom lines of the system to fixed points on the page, and spread the inner parts to fit. A justified page layout would look so much more professional. On a practical level the current layout makes heavy weather of reading a full orchestral score, especially at speed.

In reply to by Ashley Holdsworth

FWIW, a reason why MuseScore doesn't currently anchor top and bottom lines of "the system" to fixed points on the page is that in general, we don't assume there will be only one system per page. In fact, in what is probably the majority of music that is ever typeset, there usually are multiple systems per page. Eg, piano music, choral music, small ensemble music, and parts if not the score for larger ensembles. So there has been much work that has gone into optimizing the layout for all those cases, including facilities to "float" the distances between systems so you get exactly this result. But then, this complicates the job of also wanting to 'float" the distances between staves within a system, because then you have to work out how these two facilities should work together. Also the possibility of floating staff size between pages, which has also recently come up as it is done sometimes in reduced-sized"study scores". No doubt it's all solvable, and this is definitely something I would personally consider a priority for this project.

Wow, its thrilling to see a pro engraver on board! Welcome! Your posts are very informative regarding MuseScore's shortcomings as well as engraving in general.To expand a little on Marc's comments on horizontal spacing... a picture speaks a thousand words:

chopin.PNG

What makes this problem unique to me is that it is very difficult to manually correct compared to other manual tweaks. One can adjust individual measure widths (by selecting a measure and pressing "{" or "}"), but getting the spacing right requires physically measuring the distances between notes to ensure consistent spacing. And under some specific circumstances, it is totally impossible to get consistent spacing unless you adjust space note by note.

This proposed fix/design...
https://musescore.org/sites/musescore.org/files/2020-03/Improving%20Mus…

... was the result of long discussions between me and Marc which you can read here:

https://musescore.org/en/node/299741
https://musescore.org/en/node/289446

These issues are generally more visible in scores with fewer staves per system, so I expect you'll be able to see them for yourself if you create parts from your orchestral score.

Attachment Size
chopin.PNG 89.52 KB

Thanks for this work!
Please note that as a composer my workflow and needs are different from that of an engraver. As we don't have an overview of what to come (at least I don't). And things may change at any point.

These are good news. Agree very much with:

1) it should be possible to attach items to any rhythmic position.

Found this when I tried to add a piano pedal mark aligned to a position on the upper piano staff.

Using rhythmical offsets like "1/4+1/8" as user input can be very usefull and easy to understand (fractions, addition and substraction can help people to specify positions without doing calculations themself).

2) No accidentals on ornaments is a serious omission. It must be easy to do that and it must be playable.

3) Grace notes. It must be easy to create them before and after main note and they should be playable.

4) Also, an arpeggio over the lower and upper piano staff is not supported and playable.

In reply to by jeetee

In MuseScore, there are 2 versions of grace notes that are not stroked. One that is connected with a slure to the note before and one that is connected with a slure to the note after.

I think that in piano music this was used to indicate the main note i.e. which note's duration is shortened to have a time to play grace notes. I think that this system is not much in use anymore, although I think it can be usefull. So I was suprised (positively) when I saw that this appears in MuseScore. But I was never able to here a difference in playback and/or correct playback. Maybe problem was in me.

However, the manual should mention the difference between this two.

In reply to by jeetee

My first goal is to understand why there are two sets of buttons for unstroked grace notes in MuseScore, since this is not described in the manual.

If the playback is the same for the both sets and since the slure have to be added manualy, what is purpose of this? Thus, my second goal is to change MuseScore so that:

1) only one set (slur on the right side of the grace note, as is common today) exists in MuseScore
or
2) MuseScore implements two different playbacks that corresponds to two different sets of buttons.

If you can implement more than two options, even better, but you realy need an expert for grace notes (not me) who can propose a few most often needed ways of playing them.

Besides this, everything must be controllable using piano roll view. Every grace note, ornament or trill must be written out in the piano rollI view and any note (main or embellishing) should be selectable and their duration start, end, pitch, etc. must be changable. I think that now some ornaments (mordents) are not controllable in this way.

My third goal is to read an authoritative comment from an expert on music, engraving and musical software who can clarify this topic further.

In reply to by hstanekovic

The two types of unstroked grace notes allow the user to place them before or after the main note. Placement before a note represents an appoggiatura. Placement after is less common and the only applications I am aware of are a) to indicate how a trill should be terminated and b) to force an appoggiatura to appear before a bar line even though it relates to the first note in the following bar. Case b) may be used where an appoggiatura grouping includes several note (3 or more perhaps) and the engraver wants to avoid a large gap after the barline before the main note (probably a question of picking the least bad option in the engraver's opinion - not a rule). However, other traditions may have other uses for "trailing" grace notes.

How grace notes are played depends on a great many things including the traditions of the period and genre, particular composer's practices, personal taste and personal interpretation.

In reply to by SteveBlower

Thanks for a clarification. Some of these should be mentioned in the manual.

The best place to adjust playback of grace notes, trills, ornaments, mordents etc. is piano roll view. The prerequisite is that every note that is played is visible and changible in the piano roll view.

In reply to by hstanekovic

The MuseScore manual is not really the place for explanations of music theory. However, I often think that there are users who would benefit from an explanation of the more basic aspects of standard music theory and notation such as how repeats and jumps work (or more importantly what can't or shouldn't be done with them), how transposition works, the difference between slurs and ties etc., perhaps in a separate dedicated area of the website.

In reply to by hstanekovic

Well, if you don't know about the use of grace notes to end trills you won't need to use them I guess. There are plenty of things that MuseScore does that I don't understand or have never had the need to find out about, for example tab notation, bagpipe embellishments, microtones. The manual tells those who have a need for them how to add the notation. Those who don't need them don't need to worry about them.

In reply to by SteveBlower

Well, after some rethinking: yes and no. Trills with termination do not use slur. Also, there is an important case of grace notes not connected with a slur to a mesured note.

The slurs on pallete buttons might lead you to think that they should not be used for these cases.

For pure engraving matters, since MuseScore do not put slurs by itself, it might be obvious what to do. But there is also the question of playback i.e. how to do it to get the best possible playback.

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