The Beauty Oh Small Things or All About Speed

I can slowly say, that I am a very experienced Dorico user. I love the programme and enjoy working with it. Although Dorico takes a lot of work off my hands in terms of the final layout, I am still no faster than with Sibelius. Therefore, I would like to note here why this is the case. If I could only mention one name, it would be Bob Zawallich. His plug-ins in Sibelius have saved me a lot of time. But also Sibelius internal functions have been a great time saver for me. First of all, the function “automatically add slurs” when the text was already there. Also the text input with automatic hyphenation was simply faster in Sibelius, as badly as this hyphenation function sometimes worked and yes, I know Juicio Brennan’s website. I also lose a lot of time adding verse numbers in complex song structures (could there be a functionality similar to the rehearsal marks?). Analysis functions such as finding parallel octaves and fifths were small, but effective helpers in my field of work. Replacing wrong text passages or typos was also much more functional and faster. I have already written several topics about positioning texts and other objects, so I will only mention it here in passing. The fact that there is still no possibility to provide the song structure with global names (chorus, verse, …) is not so important for me anymore, because I work with a complex workaround with rehearsal marks, which is unfortunately also very slow. I could write a lot more about this, but my core statement is: actually, I personally don’t need any ingenious “inventions”, but these small and subtle improvements. As much as I like Dorico and eagerly await every update, I am disappointed that small things are postponed in favour of “big throws”. This became really obvious with the last update. A function like “generate notes from chord symbols” probably took a lot of development hours. Maybe I will be able to use it in the future, but I rarely get into the situation where I have to (or can) use something like that in my arrangements. But the little things mentioned above, I really need and use them every day and any improvement to them would really save me hours and speed up my work considerably. I don’t want to get into the discussion of which innovations are necessary or useful, but as I said, remind the team of the beauty of the small things.


I’d say every update and version of Dorico has included several ‘little things’ that make a huge difference to people’s workflows. I don’t think that’s lost on the team.

They may not have been the little things that you need — and there are certainly plenty more that I would like to see — but obviously, the team is only a handful of people, and there’s only so much they can work on at a time. However, just because someone was working on Note Generation, doesn’t mean they would have been working on your preferred features otherwise.

It’s almost as if different people have different needs. :grinning: I don’t envy the job of balancing them all against the team’s resources and capabilities.


Ben, you are certainly right. But it needs to be mentioned, that (in my opinion, of course) some major new features habe been introduced in free updates, where many people would have spent their money happily on, while there are those many small annoyances that would have fit better into these minor revisions. Correct labelling of instruments in German come to my mind, for example. It’s now version 4.3, and the default labelling of a regular trumpet still reads “Trompete (B Be)” which doesn’t mean anything at all in German.

So, while I do know that in order to stay in front of your competition and generate some positive news it is necessary to introduce new features, I really would love one or two bugfix-and-quality-of-life-only releases between paid versions. Each new big feauter with come with their own need for improvement, so let’s deal with the current debt first.

If we think about how much time a function like “automatic slurs” would save all Dorico users who also work with lyrics, it would be an incredible improvement and time saver for the whole user group and it’s not just my specific need. Dorico explicitly wants to establish itself as the fastest and most accurate notation software on the market. And this topic actually arose from the fact that I was thinking about why I’m still not faster with Dorico compared to other notation programmes, although Dorico is so much better, which I would sign any time.

1 Like

I agree with you on this one. I think it’s really time to slowly catch up on things that have been left behind. Dorico is now a very rich, mature programme, but still there are very basic things that were implemented in other programmes in very early versions.

What settings are you using on the Language page of Engraving Options? I find if I have these settings:


Then creating a Bb trumpet in a new score will label it as “Trompete (B)”.

Hi, Richard.
My selection for the third option is “Englisch (B flat / B)”.

  1. The staff labels (left to the staff in the score) reads “Trompete in Bb 1” when I set the 4th option to use symbols for flat. This is correct.
  2. If I set the 4th option to use names for the symbols, the staff label reads “Trompete in B 1”, which seems to be right at first, but in fact there is no name for the symbol (and I wonder, what this would loke like. "B be?"Probably not…)
  3. In both cases, the layout name is set to “Trompete (B Be) 1”, and “B Be” does not make any sense at all.

On a related note (:smile:), the naming of instrument transposition in the instrument selection dialog also uses “B Be” and “E Be”, and this is somewhat laughable. One of the very first things a new user will do in Dorico is to add their first player to the score, and the feeling of “They can’t even get the naming of instruments right…?” is not a very good first impression of this great piece of software.

Please keep in mind that Dorico itself is running in German on my system. This might make a difference?

Just to be clear, what name are you hoping for? “Trompete (B flat)”?

Hi, Richard.

Generally I would expect Dorico to use the same name for the score and the layout.
Since “Trompete in Bb 1” in the score is correct, I would like to see the very same term being used as layout name.

Thanks for asking for clarification :slight_smile:

Unfortunately it isn’t simple to use the flat symbol in the layout name, because - unlike the staff label - this name has to appear in various UI controls (drop-down menus etc) which don’t accept non-standard letters. We would have to spell out the name in letters, e.g. “B Flat”.

If you read the version history, you‘ll find plenty. My personal favorite is the headless notehead improvement.
Different people, different needs!


Hi, Richard.

Three thoughts:

  1. The most important thing to me is the string that appears on the top left of the player’s sheet music. This string must be correct - I guess we can agree on this.
  2. Having that said, I’m totally fine if Dorico, due to limitations of the QT framework, needs to display some “easier” (for lack of a better word) version of the layout name within the UI.
  3. Why does Dorico offer the option to use symbols in the first place if the software can’t do it? Maybe there was some regression in the QT framework in recent times (like with the tool tips), but as it currently stands, Dorico lets me choose to display symbols but then does not display symbols because it can’t display symbols… This seems somewhat upside down ,-)

On the subject of bug fixes, of the just over 200 pages in the Dorico 4 Version History PDF, fully 51 of them are lists of bug fixes, on average showing 12 or 13 per page. Conservatively that means more than 600 bugs fixed over the Dorico 4.x releases, and those were the ones that were important enough to document in the Version History (some smaller ones might not have been so copiously recorded).

And as for smaller features, even Dorico 4.3, which included both very major improvements to the Key Editor and the new Generate Notes from Chord Symbols feature, included lots of smaller changes and new features, with quality of life improvements like automatic restorative clef changes, automatic end repeat barline when creating a start repeat barline, glissando creation via popover, fullness indicators in all Engrave mode sub-modes, a new feature to export lyrics, hierarchical menus for VST instruments and effects, new note input tools for splitting notes, new faster ways to create tremolos with attack/release; engraving improvements to things like tick barlines, text borders, bar number changes, beam positioning, chord diagram fingering, bracketing for figured bass, lyric alignment, hiding noteheads, single-line percussion, rehearsal marks, system dividers, and so on, and so on.

And if you look at the other Dorico 4.x releases in detail, you’ll see dozens of other similar small improvements to workflow, note input/editing, engraving, playback, and user interface.

We can’t please all of the people all of the time, but I think it’s absurd to assert that we don’t sweat the smaller details, or see the value in small quality-of-life improvements to the software. (It’s pretty much the sum total of the kinds of things I myself work on, for example.)


You could always replace the {@layoutname@} token with the {@stafflabelsfull@} full token in your page templates.


Thank you Daniel for the profound answer. Nevertheless, I think I have not yet been fully understood. My main concern is who the Dorico software is aimed at. I work with students who want to acquire notation software. Out of 20 students in a course, 19 end up downloading Musescore and only one uses Dorico SE, although I myself advertise Dorico clearly and without restrictions. The reasons for this have already been discussed in various topics. In the perception of students, Dorico is a software for professionals, even if I emphasise the opposite. That’s why I was very surprised that a feature like “generate notes from chord symbols” took so much of your development time during the last update, because in my opinion this feature is not meant for professional users, but would be a great help for my students, but they all use Musescore. I have also never read a request for this functionality in the forum and doubt that most of the current Dorico users will use this function, as they already have enough musical competence themselves and do not want a prefabricated solution for their arrangements. At least that’s how I feel. That’s why an innovation can be so spectacular if it is perhaps not even desired and used by the current users. I never question the great and careful work you do and that you also improve a lot of little things in every update. But my initial question is and remains: why am I still so slow with this great software, although I know all the commands by heart and really know the programme well? And then there are just these little things that slow me down, and I think it’s not just me, but many other users as well. And the difference to Sibelius is also obvious. It was precisely these small problems that were not solved by the Sibelius team but by the plug-in programmers (for example: Bob Zawallich) much more quickly, which is why the users did not have to wait for years for small improvements. I really write and arrange a lot with Dorico and that’s why these little things are so important to me because they add up to hours.
Thanks for your answer anyway …

Jürg, Dorico is aimed at everybody, from students and home hobbyists up to established professionals, and across a broad swathe of use cases, from publishing to media music to church music to education, and on, and on, and on. I would love your students to be using Dorico rather than MuseScore, but it’s hard to argue with the price, particularly when Dorico SE is limited to just two players.

Your specific requests (song section markers, find/replace in text, automatic lyric syllabification, applying slurs automatically to lyrics, etc.) are all on our backlog for future versions. Some of them (such as automatic syllabification of lyrics) are anything but small. But they are all in consideration for implementation in future versions.


Good to hear that! This will make my everyday life with Dorico much more pleasant and faster.
Maybe it’s just a psychological problem: missing something is simply a stronger feeling than getting something! And hopefully this backlog will soon become a frontlog (but I don’t suppose such a thing exists):innocent:. By the way, I will stay on the ball and convince my students that Dorico is the one and only!
But enough blah blah so that you and the team have time to do your work. Many thanks anyhow!


This is literally never used in published music though, so it is annoying to have to manually edit this every time I don’t start from one of my own templates. If I add some saxes for example, I get this for Players …

… and this for Layouts:

I don’t know if it’s a default or something I did, but I’d really like the Soprano, Tenor, and Baritone to appear like the Alto without the unnecessary spelled out transposition. Unlike Trumpet or Clarinet for example, there are no other possible keys for these instruments, so the transposition label is really unnecessary as there are no other alternatives.

Is there any way to have the other saxophones default to appear the same as the Alto, without the label? If that’s something I did for the Alto, can you remind me how I might have done it? :joy: I can’t seem to figure out how to avoid these unnecessary labels with the other saxes.

I’d like to know specifically where it is impossible to display ♭ and ♯, U+266D and -E. Every platform that Dorico runs on supports Unicode, and those glyphs have been in Unicode since 1991.

It’s not a Unicode issue, but rather a font issue. In general the labels in our UI don’t support rich text, so it’s awkward to make Dorico choose a specific font for a particular character. Most text fonts, including the Windows Segoe UI font used as our UI font on Windows, and the Source Sans Pro font we use on macOS, don’t include the U+266D–U+266F symbols. As such, we would be at the mercy of whatever gets substituted on each individual user’s system, which is something we want to avoid.

In any case, that really has no bearing on what is displayed in layouts themselves. At the moment, this uses the {@layoutName@} token, but it could potentially use something else.