Dorico 2 Pro bugs/enhancement requests

  1. If you’re generating PDFs rather than actually printing, you can ignore the paper size that appears in Print mode. It’s utterly irrelevant. The only page size is the one that appears in Layout Options.

Pianoleo, I think that is correct so far as generating the PDF is concerned, but not if you look at the print preview.

I was recently working on a score on landscape paper (which is conventional for organ music), and got a shock when the print preview shrank it onto portrait-shaped pages with half the height left blank. Resetting the paper size sorted that out.

Thanks to all for your responses. I guess that I find these behaviors less than intuitive. Specifically:

  1. Why should a change of note head size to indicate an alternate but less desirable note not propagate to the part layout? I do not understand what benwiggy is saying about “Propagate Properties”.

  2. The change of the word “cresc.” in the score to a hairpin in the part makes no sense to me at all, especially when “poco a poco” is affixed.

  3. I understand what dankreider is saying about page numbers. I hope that having the option to place them on the outside edges of layouts automatically will be an included feature soon.

  4. benwiggy has suggested that I have manual overrides in my layouts. When I create a new master page for a title page and save it, then add it to existing part layouts, it does create an override since it is not the default first page. If I change the master title page layout, not the individual part layouts, this does not get reflected in the parts. I would have thought that it should carry through since it is not really an override of the individual part but simply a change to a master page.

  5. It is good to know that pdf’s will print correctly. I guess it would be nice if the paper size chosen in the Layout Options automatically appeared in the Print layout, especially if I am using a specific printer, as Ron Tully suggested.

  6. Thanks for the suggested sequence for changing instruments, benwiggy. I’ll have to try that.

  7. Does anyone have an answer to my 7th point about having to load sounds manually into HSSE? It seems that this happens for all sounds patches assigned automatically to HSO in Endpoint Setup. Is this a behavior others have observed or does it indicate a problem with my installation?

I really appreciate all the help.

Property changes do not carry over to other layouts currently. This behavior will be improved in the future, but for now, you need to manually popogate any property changes to all other layouts.

It’s not difficult to incorporate into your workflow - assign that function to a key command and just do it when you make a change through the Properties Panel. I assigned it to Ctrl-Alt-P.

When I create a new master page for a title page and save it, then add it to existing part layouts, it does create an override since it is not the default first page. If I change the master title page layout, not the individual part layouts, this does not get reflected in the parts. I would have thought that it should carry through since it is not really an override of the individual part but simply a change to a master page.

Read this, it should help:

  1. is annoying. I’ve never heard anyone want hairpins or cresc. to be different between part and score. It’s definitely one that should propagate on its own.

I’m resisting the temptation to use a shortcut for propagate… Cmd-A, 4, U in Finale was the bane of my life, as I constantly did it automatically in Logic, Scrivener, Nisus, Safari, DP…

I use Ctrl-Alt-P. I use it constantly and don’t mind the imposition. But as you said, some properties should be automatic. Doubtless they will be, in due time.

To me, the word ‘cresc.’ feels entirely different than a hairpin. A hairpin is very local. A cresc. is often something longer, implicitly until some other dynamic, or just according to taste. It’s not an exact science. Same for dim. and >. It bothers me somewhat that Dorico considers them to be equivalent.

Likewise for rit., rall. and pesante.

I consider hairpin and cresc. similar, so I understand Dorico’s choice. To me, the main difference is the number of measures the change in dynamics takes. I rarely use “cresc” and even less frequently “poco a poco cresc.” I would be more likely to write “Build energy” or something like that, simply because there aren’t enough gradations in volume for a 10-bar crescendo to actually make any sense. A 10-bar “cresc” really means get gradually louder, more energetic, more intense etc.

I find musicians tend to ignore the written-out “cresc”, which is why I take more of a Percy Grainger approach to instructions. I.s. say what you really mean. Musicians will take more notice that way.

Thanks for all your responses. Here is my take on all of the issues I raised:

  1. Change of note head size (specifically cues) do not propagate to parts:

I hadn’t noticed the Propagate Propertries option in the Edit menu. My mistake.

  1. Change of cresc. in score to hairpin in part:

Judging by this and other comments, changes to this behavior might be forthcoming.

  1. Automatic mirroring of page numbering:

Good to know this will be considered later.

  1. Changes to user designed title pages in master sets not propagating to parts:

An excellent tutorial. Thanks. I now see that I was adding a title page to the beginning of the parts by using the plus sign rather than modifying page 1 to use the title page master and page 2 to use the first page master. Not exactly intuitive but now I understand what I must do.

  1. Page size not propagating to the print section:

Nice to know but I would still like to see consistency between layout options and the Print section.

  1. Problems with playback after changing instruments:

Thanks for this suggestion.

  1. Having to load sounds manually in HSSE when Dorico assigns sounds based on HSO in Endpoint Setup:
    No-one has suggested a fix for this so I presume I have an installation problem.

Thanks to you all.

  1. We’d all like consistency between Layout Options and the Print section.

a) the Print Preview thing is provided by the Qt framework. To get consistency the Dorico team would have to start again from scratch, which strikes me as pointless given the existing system works
b) the Printer page sizes are provided by installed printers.

I work with A3 scores but don’t own an A3 printer. I certainly don’t want to be prevented from exporting A3 scores…

For the Page Number issue, you can make the Text Frame span the whole width of the page. It uses the Outside Edge alignment property which will solve your problem. I would also move the FlowTitle frame in a bit from the edge, so it’s easier to select the frame you want when editing.

A really basic question here – and maybe I am in the small minority – but why wouldn’t you expect ALL attributes INCLUDING POSITIONING, to automatically show up in the parts? It seems to me that propagation of everything ought to be the default. Or at least the propagation state ought to be toggle-able, like insert mode or chord mode. If I really think hard about it, I might come up with an example where I’d want some different properties between parts and score, but surely that is the exception and not the rule.

For the nth time, Propagate Properties is an interim measure that will eventually be replaced by something better.

Two situations where you don’t want them the same:

  1. Nudging dynamics out of position in the score to save space, but leaving them correctly positioned in the part.

  2. Tweaking the shape of slurs etc differently in a concert pitch score and a transposed part, because the slurs and note stems have changed directions.

With a bit of thought, I’m sure I could come up with more. But as pianoleo said, this cracked record has been stuck in a groove long enough already IMO.

Sorry I wasn’t aware of that. I do try to watch most of the videos and read threads that see applicable to the issues and I have never come across that. it seems to me if it is such common knowledge, perhaps the videos and blogs that introduced the features should have begun with such a caution.

If it comes up enough to irritate you, that’s probably because it seems to be a pretty big defect in the program. Fortunately I haven’t used properties too much, but now I am wondering how many parts I have put out without realizing I needed to go back and edit properties in the parts.

Craig, see

Thanks. I had not seen that. One of the challenges of using what really is still an alpha or beta level product is that information tends to be scattered all over the place. I know the team is hard at work truing to bring documentation up to a more useful level, but that’s not an easy task, considering how rapidly the product is changing. I’m sure that if the team had the luxury of taking an additional 2 years to bring the product to market, it would be a different situation.

Regardless, I still raise my voice to say I think the bias should be toward propagating everything (at least when working within the score), and making the non-propagation the exception.

I wasn’t aware there were two different programs called “Dorico,” and I wasn’t using the same one as you.

Well, you learn something new every day here.

I might not have been so spicy about it, but I do agree that Dorico is not at all a beta product.

I have no doubt that if development were to grind to a halt as it has with the other two big programs, we would surely see more stability of these tiny little issues. Personally, I much prefer the rapid and exciting pace. And honestly, how many truly problematic bugs are there? Anyone? Bueller?

If you want development, it’s inevitable there will be kinks to be worked out. That’s not “beta”—that’s progress.

Wait, I take that back. As F and S have demonstrated, it’s possible for a software to make absolutely no substantial progress forward, AND yet never fix its bugs. If that’s the definition of beta, then they’re all beta.