Just wanted to let you know that putting parentheses around dynamics in the score doesn’t transfer to the parts. In the parts, no parentheses.
It’s not a bug, per se. The team has stated that it is by design that some properties don’t transfer from one layout to the next. Accidentals are one of these properties, since transposition, for example, can powerfully shift the context. Daniel has stated that the next update will bring about a shortcut to switch between full score and part, so that these kinds of changes are made in conscience by the user.
Well, it may be by design, but in this particular case it’s exactly backward. The easiest way to see the context that determines whether or not a reminder dynamic is appropriate is in the score. Also, in the score you can add them to multiple verticals parts quickly.
But putting them into the score, where it’s easy and convenient, doesn’t get them where they need to be—in the parts. They don’t even need to be visible in the score; they are reminders for the players, not the conductor.
If this is going to stay this way, I certainly can’t afford the time to use them. I’ll just leave them out or put them in as regular dynamics, which can look pretty silly to the player when they’re fairly close together.
I really hope there will be a better fix than just making it easier to jump back and forth from score to parts; to me, there’s no more basic concept than the idea that whatever goes into the score goes into the parts unless you tell it not to.
Ta-dah. Your idealized scenario is one where the accidental, by your account, doesn’t even need to be displayed on both places, thus legitimizing the design option.
I’ll be perfectly honest, I’d rather have more rather than less properties be inherited by part layouts from full score layouts myself, I was just trying to relay the state of the art. This might even be changed as the software is refined, but Daniel has provided grounds for this behaviour and, by your own account, he’s quite on the mark.
In your case, with the shortcut in place, instead of selecting a note and changing the property, you select a note, hit W and change the property.
What accidental r u talking about? I’m talking about dynamics w/parentheses.
And it’s fine if the appear in the score. The point I’m trying to make is that if putting them into the score made them appear in the parts, you could just put them all into, say, all the brass parts very quickly and easily. If you have to put them into each part individually, one at a time, it will take at least five times as long, and that’s conservative based on an experiment I just did.
Sorry, I started talking about accidentals to provide further context, since the mechanics are the same, and then got them mixed up. Again, I’d prefer if more rather than less of these properties were inherited by part layouts, but, as it stands, this is the default behavior. Hopefully it might change in the future.
I just can’t for the life of me understand why stem directions, noteheads, and other properties don’t transfer to the parts, or even pasting into adjacent measures.
I just can’t for the life of me understand why stem directions, noteheads, and other properties don’t transfer to the parts, or even pasting into adjacent measures.
Changes in stem direction aren’t inherited by parts because this would be actively unhelpful in the case of transposing instruments. Now of course you might have a transposed score and transposed parts, in which case they will always match, and you might also have no transposing instruments at all in your project, and given sufficient time and motivation we could of course add logic to link them together when it makes sense, but we try to have whole classes of things work in the same way so that the program is at least predictable.
I would not pretend that we are 100% happy with the way this stuff works, and I am sure that we will come up with some good ways to improve this in future, but it has to be done carefully and without sacrificing Dorico’s flexibility. We do not want to link things together that then reduce flexibility to the point that people can no longer control the appearance of layouts sufficiently independently that they cannot produce scores and parts comfortably from the same version of the same project.
Thanks for the as always thoughtful reply, Daniel. I really do understand the issue of prioritizing the things your team is working on, and I can see how making parenthesized dynamics transfer from score to parts would of necessity be a low priority.
So I’ll just go back to my original issue and request that they go onto your “someday” list. They really can be put into multiple parts quickly in the score, but putting them into each part separately takes enough extra time to make it impractical for “deadline writing.” (And what other kind is there!)