Some questions and suggestions.

#3: not yet

#5 & #6: Not to pick on Leif, but I am kind of amused how often requests are made to save one keystroke in a user’s specific work process. Not that these things would not be useful, but that it is still early in this program’s development and the roadmap presumably has more important fish to fry (chords, percussion layouts, and repeat endings come to mind based on user requests).

#4, #7, & #8 have been addressed already, either planned (7) or explained (4, 8) in current state.
https://www.steinberg.net/forums/viewtopic.php?f=246&t=105110&p=577323&hilit=swap+voice#p577323
https://www.steinberg.net/forums/viewtopic.php?f=246&t=113914&p=622596&hilit=caret+note+direction#p622596
https://www.steinberg.net/forums/viewtopic.php?f=246&t=109591&p=602118&hilit=properties+switches#p602118

#9. Actual tempo markings (as opposed to tempo change markings) can be created via the SHIFT-T popover and existing marks can be edited via the Properties panel.

Thank you, Derrek.

#5-6 Not to (not) pick back, there already seems to be quite a number of customizable default values, so it feels to me as a design choice always to be given the option of printing first. I’m not a programmer and have no idea how complicated it would be, but I’d expect it to be quite simple compared to so much else that Dorico does brilliantly. About grace note slurs as default, I stand by my suggestion - I think it would be a great detail and just in spirit of Dorico “just knowing what you want”. Grace notes are obnoxious enough to work with anyway. And I haven’t seen this discussed anywhere.

#9 I don’t think you understand (or I don’t). I want some markings - in particular rit., rall., and accel., to show as non-bold italics, which I can’t make happen. In Sibelius, I use to create the marking and then change it to non-bold italics via the text editor - cumbersome, but possible. It always annoyed me that I had to do this, since it’s a very normal way of notating these things. Am I missing something?

Anyway, thank you so much for pointing out the threads I had missed. It’s a great help. And sorry for posting about topics already discussed.

I didn’t comment on the portion of your point 9 that discussed the font style of tempo-change markings because I have not dabbled with them enough to know if any means to change them exists. Perhaps one can alter the paragraph style, but I have not explored that or heard anything that suggests it is possible.

If Dorico decides to create a means to print to PDF as a default, I am fine with that. I just read what seems to be so many posters impatient for one-key solutions to solve (what to me are) minor problems compared to the large chunks of the program yet to be implemented. I recall the progress of Finale from the first version on; convenience options grew as the program matured, and I am sure the same will happen with Dorico.

Like you, I have great confidence in the Development Team.

I’ll look into the paragraph styles and see if I can find something. Thanks for the tip. Please understand that I have not been around notation software nearly long enough to remember the launch of Finale.

And just for the record: I’m not impatient, just quietly pointing out a possibility for a (I agree) minor improvement. If it gets on the list of the tenth update from now, mission accomplished.

FWIW…

  1. What’s the reason for the switches in the properties panel? It seems superfluous to turn a switch and THEN choose an option or click a box. I know you’re working on some sort of keyboard control, but still.

I understand the given answers to this, but still think that Dorico is asking me to explicitly define programming variables that should be behind the scenes.

In a nutshell this is because these settings are overrides from the defaults. If the switch is ‘off’ then that means Dorico will do the default. If it’s on then means the user is telling Dorico explicitly the state they want. So effectively the switch and the button encode 3 states: auto, on and off.

I still don’t get why that is then not a button with 3 states, rather than two buttons?
It seems like a programmer’s answer.

The reason is because then every control would require 3 states, and most types of control are just not amenable to that. Arguably introducing tri-state controls would add more cognitive load on the user than separate buttons: one to say whether you want to make an explicit choice about the value, and one to say what that explicit choice is.

Ok. But would there be anything technical (or philosophical) against the switch switching itself? Like for instance that clicking on up-slur (when down-slur is default) would make the switch turn on by itself. Now it’s on, and the user can see that defaults are overridden etc. This has been debated in another thread, but was not really answered. I completely understand if you just haven’t had the time for implementing this possibility, but I don’t understand it as a design choice.

I think LeifG is right. It is not a big change for the user, switching only one button instead of two, but would make the user experience way more intuitive and straightforward. And I also understand that this kind of “cosmetic” improvement is not high on the list of “to do” things :wink:

I can see what you mean, and I can understand the convenience of that. However you would be in a very grey area in terms of UI consistency because that means that clicking on a control that is disabled would have the effect of enabling, which kind of defeats the object of showing it as disabled… Also from a technical point of view, a disabled control doesn’t respond to mouse clicks. If we didn’t disable it then it would show as enabled, which suggests that it’s active, but it isn’t, so that would be misleading.

Tri-state situations are very tricky things to deal with in a way that reduces the cognitive load on the user and fits in to existing UI paradigms. Any approach is necessarily going to have some trade-offs, but we believe that our current approach does show you unambiguously what the current state is, at the expense of requiring an extra mouse click to activate it.

I still think this makes sense to code and not to use.
Why can the setting not just show the current position, then remember if I explicitly change it?
So for example an accent is above or below automatically and changes automatically if I alter the note etc, BUT if I explicitly set above to below, then that sticks.

I think when people are just repeating their arguments, it may be time to agree to disagree for the present. If the Dorico team decides eventually that it makes sense to implement something akin to the “checked-unchecked-shaded” checkboxes Finale uses to show checked, unchecked, and “leave it alone” (default?) states in their Staff Styles panel, then I’m sure they will. But for now, I get the sense from Paul that the issue is not on the table; the team is working on more important issues than an extra mouse-click.

I thought it was a conversation that was moving forward. I’d like to understand the philosophy behind some of these things. I have no doubt that the team have been round and round the architecture of these things, and hopefully will teach me a thing or two.

(Also, I don’t expect the Dorico team to answer everything and am happy to be ignored!)

For what it’s worth I like the way it is implemented; often when I click the switch to override default behavior, it will automatically select what I was going to do anyway (change a slur from under to over, for instance). I like being able to glance at the properties panel to see if an item is switched on or not.

And the color scheme in general is quite beautiful, which really makes a difference.

FWIW, we would like to have the ability to show the current state of the value that the control represents. However there are major technical hurdles to that, because in many cases Dorico only calculates the optimal value for the property at the time the score is laid out, and it may change depending on the context (eg deleting nearby notes may cause the casting off to change).

One thing I forgot to mention earlier is that these controls are not options, they are properties. That may seem like a minor semantic point but the key thing is that a note (or other item) only has properties for the things the user wishes to override. If the slider isn’t ‘on’ that means that the property doesn’t exist and Dorico will calculate an appropriate value on the fly.

Regarding the OP, #9: In Font Styles, i found out that I can change the font for gradual tempo to non-bold italics and get exactly the result wanted. And way more elegant than the way I used to do in Sibelius. Unfortunately, it only works for a few specific words (ritardando and (as far as I remember) allargando with abbreviations). For instance “affrettando” - which is definitely a gradual tempo marking - will not be recognized as such and thus be written with the immediate tempo font. Is there plans to expand Dorico’s musical vocabulary in the foreseeable future? Also, no matter what, it could be useful to be able to override the chosen font in specific cases. Or even be able to “teach” Dorico a custom vocabulary. Particularly if you use non-standard markings in less known languages.

By the way, I need to express my gratitude for this terrific piece of software! I am in the middle of my first bigger project using Dorico, and it’s such a pleasure to work with. My workflow is already way faster and more satisfying than ever before. Thank you, Dorico Team!

Leif, re: your #9: I stumbled across the answer to that this morning. It is in Engrave:Font styles, and it represents one of Dorico’s very clever attributes.

There are two settings for Tempo text, Immediate Tempo Change and Gradual Tempo Change. I was faced with the same issue: rit, accel, etc. in large, bold font. I set the Gradual Change font to a smaller, italic (non-bold) font, and then started wondering how I tell Dorico which marking to use, because there is only one Tempo tool.

For want of anything else to try, I typed in an accelerando and hit Return. To my surprise, the accel appeared in the small italic font. Certain that I had somehow messed up the whole tempo tool, I did the same thing again, and this time I typed Allegro. Presto – large bold print; Dorico recognizes the difference between Gradual change and Immediate change tempo terms.

I love this application!

Leif, it is definitely planned that you should be able to teach Dorico some new tempo words in due course.

I’m really glad that you are enjoying using Dorico so far. Please tell your friends and colleagues how much you like the software and encourage them to give it a try.

Leif, re: your #9: I stumbled across the answer to that this morning. It is in Engrave:Font styles, and it represents one of Dorico’s very clever attributes.

There are two settings for Tempo text, Immediate Tempo Change and Gradual Tempo Change. I was faced with the same issue: rit, accel, etc. in large, bold font. I set the Gradual Change font to a smaller, italic (non-bold) font, and then started wondering how I tell Dorico which marking to use, because there is only one Tempo tool.

For want of anything else to try, I typed in an accelerando and hit Return. To my surprise, the accel appeared in the small italic font. Certain that I had somehow messed up the whole tempo tool, I did the same thing again, and this time I typed Allegro. Presto – large bold print; Dorico recognizes the difference between Gradual change and Immediate change tempo terms.

I love this application!