'cresc.' creates a hairpin

Why does Shift-D ‘cresc.’ create a hairpin? If I type cresc I want cresc. If I wanted a hairpin I would have used Shift-<

Set the Gradual property on your hairpin to “cresc./dim.”

Yes, I know I can do that, but why?

If I go out of my way to make 9 keystrokes, when I couid have made 2, it’s frustrating that the software isn’t respecting my clear intent. Why even have the text entry then? It’d be faster to create a hairpin and then muck with the properties.

It’s a clear violation of the principle of least surprise.

If you type something like "dim. molto’ it’s even worse, as the molto gets dropped entirely and again you have to muck with the properties panel.

Just an idea… I’m not certain of the rationale.

By starting with a hairpin then converting it to text, you define the total duration of the crescendo. Playback can then take that into account.

In the popover you can enter a chain of dynamics like “pp<mf<fff” and Dorico will space everything correctly.

You can add “molto,” “poco a poco”, etc with a single mouse click in the right hand “dynamics” panel - you don’t need to keep retyping the same words.

The basic “surprise” here is that Dorico works on the semantics of what you are entering, not on its visual appearance. In other words, you are creating “a crescendo mark”, not “some text containing the letters c, r, e, s, c - which doesn’t play back unless you create a hidden hairpin as well”.

You can display the crescendo mark different ways with the properties box, and if you decide later on to change “cresc” to a hairpin, you don’t have to delete one notation and re-enter the other one.

It feels like we’re talking past each other.

Dorico is obviously smart enough to figure out the semantics, why can’t it/doesn’t it set the properties to be inline with the way I create it? Why is the extra step required?

We do it this way, for what it’s worth, because we made the choice to not set properties on items created via the popover by default. It’s been debated a lot within the team and also by our beta testers, and I’m certainly open to us changing this behaviour in due course. The reason we decided not to set properties by default was so that when you change e.g. the options in Engraving Options, all of the things you’d created either using the panels or via the popovers would update when the options changed, unless you had explicitly gone and set the properties yourself. We thought that since the Properties panel is hidden by default it might cause some consternation if some items in the music would update when the defaults changed and others would not, unless the user had explicitly stated his or her intent that a particular item should be different from its defaults in some way. Obviously the converse is also true.

I’m assuming this idea – that popovers do not change properties – is also the reason that when I type in “(f)” nothing happens? I understand your reasoning, but it’s definitely setting us up to spend a lot of time fighting the program. For example if I type “Allegro (q=72-96)” the program gets confused and inserts “Allegro (-96) q=72”. To create that tempo marking correctly requires several mouse clicks. As an aspiring power user, I want whatever I type in the popovers to be matched as closely as possible – I for one would like to vote against the current behavior. The program is so smart, how about letting us take as much advantage as we can?

Jeff

One of the major design decisions in Dorico was that we wanted to move away from the Sibelius-style way of doing things where the user enters text for dynamics, tempo, etc and then the application tries to interpret that when you play it (remember needing all those ‘~’ symbols in Sibelius?). It’s all just text, just with different styles and implied behaviours.

Our goal instead was to capture the musical semantics of every item in the score, as best we could, so that it could obey the desired rules for formatting (eg the way that tempo items know where to align horizontally) or playback.

Dorico does try to interpret a range of common dynamic or tempo markings, where it will try really hard to extract the semantic information, but preserve the visual appearance. It won’t work for all cases however, and yours is one such example. We can look at beefing up the parsing to try to preserve what you had typed more gracefully.

Do you think it would ever be possible to have both options available in the gradual dynamics toolset? Something like this:
ex1.jpg
…that way one could get the desired result immediately, both visually and semantically. A lot of music picks and chooses between hairpins and words depending on the context, the first score I picked up from my table to look for examples of gradual dynamics is about 80% hairpins, and ‘cresc.’, ‘dim.’, ‘diminuendo poco a poco’, and so on for the rest.

Quite possibly. Nothing is set in stone just yet!

Enters idiot, asks:

Does this mean you can’t have both a hairpin and the text “crescendo” in the same score?

Shortly thereafter …

Found it! Properties panel.

You can select how to display each dynamic mark with the Properties panel. The thread is talking about how to specify different options when you create the dynamic mark, without having to set the Properties.
cresc.png

“Our goal instead was to capture the musical semantics of every item in the score”

I think that there is a problem here is that someone has decided what has meaning and that meaning is prescribed.
To me there is an emotional difference between writing a hairpin and ‘cresc.’ I find that the difference that I want is followed by players without explanation. I don’t care that playback will never pick this up, I should still be able to score it at first go.
I’ve also stacked accents, staccatos and fermatas, and had individual lyric syllables all at different heights (and a host of other things…). In 2016 I should be able to use symbols and text in any way that suits, rather than an imposed musical grammar.

Steve P.

I think there’s an inherent conflict here. Dorico can produce more beautiful results by default than other scoring software because it has an understanding about how most (and I do say most, and by no means all) music using common Western music notation looks. This understanding comes about through algorithms that we have designed to handle many, many combinations of musical situations. Of course there are limits to what the program can do on its own, and it’s never our goal to prevent users from being able to produce whatever graphical result they may want, even if they have to paint outside the lines a little to do it.

At the moment, Dorico doesn’t have as many ways to break the rules as we would like: you mostly have to use the Shift+X text tool to produce either text instructions or musical symbols (by setting the font to Bravura or Bravura Text and finding the appropriate symbols either to insert using an application like PopChar or using the tables of symbols found here), but those will all come as the application matures.

Hopefully the flexibility that is shown by the already hundreds of different engraving, notation and layout options that we have added, plus the dozens of editable properties for most items, and the overall approach shown in Engrave mode, demonstrate that we do not consider there to be only a single correct way to communicate a musical idea. But it will take time to add more options to work outside of Dorico’s carefully crafted algorithms, just as it will take time for us to carefully craft further algorithms to handle the notations that Dorico does not yet handle, as beautifully and as automatically as possible.

There may be an inherent conflict, as I said at the outset of this reply, but I don’t see it as an insurmountable one. If you don’t find Dorico suitable enough yet for your needs (I know you are a very long-term Finale user, so you are used to doing most of the work yourself, and probably happy enough to do it, most of the time), then don’t write it off altogether, but check back in some months from now and see how we’re progressing. I would wager that we will have taken further steps forward in that time than your current software, whatever it is, will have done.

Hi Daniel,
I’m three days in trying to do work exclusively in Dorico (although I know that I’ll do it again in Finale). For me, it’s the only way to see if the program can do what I want. I’m actually falling in love with Dorico a bit and expect that in a year or so it will be the only thing I use for writing (scores, not playback). So many things are way quicker than Finale or Sibelius now that I have the popovers down. The options even allow for my own preferences between modern/old ways of engraving.
BUT… I do feel a bit as if Dorico is telling me the right way top do things and is difficult to ‘break’. For me, the design of a score is part of the composition, not just a vehicle for its transmission. I’m pretty sure you think similarly. Finale’s weakness was that a lot of things required kludges. Dorico’s (at the moment) is that it is resistant to kludging!
Steve Parker

I’m pleased to hear that you can see things you like in Dorico. Prioritising the hundreds, if not thousands, of things that we need to work on to satisfy the incredibly broad and deep needs of musicians is perhaps the biggest challenge we have in front of us. I hope that you will find our philosophy amenable: we want Dorico to do as much automatically as it can, on the grounds that if we can make the software do automatically what you would have done anyway, we will have saved you time; but we also know that there are many different approaches to more or less every non-trivial situation, and we want to provide users with tools that allow them to achieve the results they want. This introduces a big tension, no doubt, because automation and case-by-case customisation are in opposition, but we will do our best to balance both sides of this scale as we continue to develop the software.

I’m anticipating a similar experience with Dorico, although it’s still much quicker for me to enter certain things in Finale than in Dorico. Nothing can beat Finale’s metatools, where you can simply hold down a self-programmed key and the program will enter a dynamic or an expression of any kind. Dorico’s way of entering its eight pre-set articulations comes close but dynamics take many more keypresses and/or mouse clicks. To speed things up a little, I’ve made quick macros (in a third-party program) for the most common dynamics. As usual, the ‘problem’ is actually one of Dorico’s great strengths: it needs to understand what you’re entering which, in the long run, is really the best way to do anything.

I’m of two minds about Dorico’s telling me ‘the right way’ to do things. That’s one of the reasons I prefer to use Finale instead of Sibelius; I don’t need to be told the right way to do things and there are just too many situations that a program can’t anticipate, and it is in those situations that Finale offers me the freedom to do what I need to do. On the other hand, I’ve seen, had to play from, and even had to clean up too many really badly set music made by programs which left too much up to users who haven’t either the expertise or the interest in setting music correctly at the very least and, preferably, beautifully. As a Finale user who spends a lot of time getting the desired results, I’ve seen that Dorico’s second release already does a lot of this well, intelligently and automatically. I’m looking forward to Dorico’s future developments with great anticipation!

Yes, but nowhere near as much consternation as having my text input discarded without explanation.

To my mind the problem with the concept is that one default appearance precludes the other on first entry. Hairpin and “cresc.” are both important enough that neither should replace the other on input. They may be quite synonymous for playback purposes, but they have different shades of meaning to humans.

I agree with Mark on this point – if I enter ‘cresc.’ or ‘crescendo’ I want to see ‘cresc.’ or ‘crescendo’ in the score and not a hairpin. If I enter < I want to see a hairpin. We should not have to go to the Properties panel and change things manually - that negates the flow of entering the music and gets into “engraving” situations, which should not be part of the “writing” process. It really slows things down for entering the music initially, and the choice of using hairpins or the words is for me at least an important part of “writing.”