Locally vs. Globally

I have a score where I want the Metronome Markings+text to show in the score but only tempo text in the parts. I have played around with the globally-locally properties a little, without any result.
Is the thing that I want even possible?

You have to do a little trickerydoo:
Add one of those on beat 1, and add the other one a 1/64th later. Then you can hide one in the score and the other in the parts.

1 Like

So I have to use a workaround because they didn’t separate the score from the parts in this instance. Very crude formulated, I know, but I hope you get my meaning.
To bad I don’t do workarounds. Either the software is capable or it is not. Hip hurra for the digital conservatives. :slight_smile:

I know this feeling too well :wink:
It’s all about “how important is this thing that I want to achieve”.


A workaround is just “something that takes more steps than I would ideally like”.


If my exact requirement is not possible at this stage of Dorico’s development and I have to use a workaround to achieve the end result that I want, I’ll take the workaround any day.


One of the most important reasons I don’t do workarounds, is the claim that Dorico is faster than other notation software. But with every workaround the workflow is getting slower. I know Dorico is still a relatively young program, but it seems to me that some of the things we are doing workarounds for is pretty small things that easily could have been programmed from the start. I am beginning to suspect that the programmers have to meet fast deadlines by which they have to gloss over things, that might not seem important to the moneymen. But that is purely speculation on my side.

Yes. Yes it is.

But I don’t understand – if you have to use a “workaround” to achieve something, you just won’t bother achieving that result?

1 Like

Perhaps the programmers worry that “with every [programming] workaround [their] workflow [might get] slower.”

I don’t pretend to try to deduce the Development Team’s motivations, especially considering how much effort they spend listening to and helping those of us who use their program.

If I want something enough, I don’t mind putting in the effort to do whatever is possible to achieve it.

1 Like

Yeah… well… Everybody got a streak of stupid in them.
So this is a bit of my stupid streak. :slight_smile:

Unless you think of me as one of “the moneymen” because I’m Dorico’s product manager and the person who ultimately sets the priorities for what we’re working on, I can tell you that upper management at Steinberg do not interfere or even express much of an opinion on precisely how we choose to spend our development time – and that’s true for all of our products. They trust the experts they have hired to build these highly specialised, unique tools, and they don’t micromanage.

(I certainly don’t like to think of myself as one of the moneymen, because here I am sitting at my desk at midnight answering questions from our users and hoping to be helpful! I also spend most of the time that I personally work on Dorico from a development point of view attending to tiny details, things that might otherwise slip between the cracks, and I believe we have an especially keen understanding of the big differences apparently small changes can make to users.)

The specific reason why you can’t set the properties for whether metronome marks and tempo text are visible in different layouts is because of the way we set up that data many years ago when we were first designing the implementation of tempo items. We were working to the best available requirements we had at our disposal at the time, and architected the data design to accommodate those requirements. When new requirements emerge that we didn’t account for in the original design, we have to consider how to accommodate those requirements. Because the data about what kind of data is shown for a tempo item is intrinsic to the item, it’s not simple to change this.

However, we know this is a requirement that users would like us to address, and it’s on our backlog of things we plan to change in future.