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. 
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.
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)â.
- 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.
- 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âŚ)
- 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 (
), 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 
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:
- 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.
- 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.
- 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)
. 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? 
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.