Wauw. How did you put this in Dorico this fast! Can you enlighten me, what software do you use? Or are you lightning fast? I that case I’m going to hire you. No need to remove the file!
Thanks! I will experiment with that. As I asked: I think I’m missing something in preferences, and it might me wise to dive into that soon. I’ll check the avoid collisions option! thanks again!
You can check the preference differences between @Christian_R 's file with yours using the Library Manager
(I just used Dorico. I live recorded the chord and melody with a MIDI keyboard, then adjusted the result and added the rest of the music with the normal workflows of Dorico.)
I think being able to individually remove rehearsal marks from the vertical spacing calculation as Benji suggests might be a better way to go rather than a recalculate button. When I have multiple items appearing at the same location, there will already be enough vertical space once the tempo indication, system text, etc is accounted for. If I’m going to have to manually reposition elements manually, a way to simply tell Dorico not to consider that rehearsal mark in the spacing algorithm seems like a good solution.
I’m game! Let’s hope it will happen.
@Christian_R great! I hope I’ll be this swift some day!
I second RoelVanWijks experience in needing a kind of “recalculate vertical spacing”. I literally have this with every part I layout for musical theater scores. This will probably not be solved by optimizing Rehearsal Mark positioning alone because there are always items here or there that would not layout themselves automatically properly.
The scenario is usually that Collision Avoidance stacks many items on top of each other, creating large gaps between systems. After manual adjustments and proper (horizontal) distribution of those items, I need to readjust the vertical spacing between the staves.
One of my ways to work around this is to disable Collision Avoidance for those items, hence creating too little vertical spacing first, and then increase it from there. Both approaches are not ideal, though, in that they both require manual intervention of system spacing.
So ideally the layouting would be: first-pass initial layout with vertical spacing, then manual adjustment, then second-pass final layout with re-calculated spacing.
I realize that this is not a trivial thing to implement because we would need to tell Dorico whether we want our manual adjustments to be applied to the first or the second pass. However, there is a serious amount of time spent on these spacing corrections, so an effective solution to this would be a huge time saver.
Thanks @Marcus-de for describing the problem in calm, clear language! Most of the time when I’m confronted with this behaviour, I’m in a fair amount of deadline stress, and my English is not great. I deal with this issue every day, and I realize that it’s because of the rest of Dorico is so well made, this sticks out. It makes you think, moan, shout: whyyy?
Another Why: I’ve already said this, but I can’t imagine there’s soms advantage in Dorico going from Galley to Page when going from Part to Score. This is not necessary, I can’t think of a situation where you want to go to Page when you swintch to Score. I can imangine wanting the other way around: when in Page: switching to score, Dorico would remember that you were in Galley and stick to it. Is it okay for you nice people that I call that a bug? It doesn’t serve anyone and is really annoying when doing the final tweaks of a large project.
I think this has been discussed before. Dorico remembers the last view for each layout in Write mode. If you’re viewing one layout and switch to another, Dorico will use whatever view you were last using for that layout, rather than preserving the view from the first layout. This seems like a reasonable choice to me, keeping in mind that no matter which way the dev team decided to handle this, some people would be unhappy. (Although I guess they could make this configurable.)
A software bug is something which doesn’t behave as the developers intended. If the devs intended for the view mode to be sticky when switching layouts but it’s actually not working that way, that would be a bug. Something that’s working as designed, but not the way that a user wants, is not a bug. In other words: just because something “bugs” you doesn’t mean it’s a bug!
“If you’re viewing one layout and switch to another, Dorico will use whatever view you were last using for that layout, rather than preserving the view from the first layout.”
It doesn’t! I just tried:
Write mode/score/galley → I switch to Engrave, then g to a part. Then I go back to write mode, I’m still in part, indeed Galley. When I switch back to score, it changes to Page instead of Galley, while it was in Galley before, it doesn’t remember that.
I now changed my preference view to Galley, and it still happens! In the final stages of working on a large project I do this a lot: working in Engrave/Part, and then quickly want to change something in the musical material, so go to write mode: I’m in part/galley (this I never need, but okay) and then, when I switch to score, it goes to Page mode and not Galley! Everytime. So another change is necessary and it can take a long time to switch to galley then. This might be a bug then? I can’t imagine they intended it to behave like that.
That’s interesting. I was thinking that maybe switching to Engrave implicitly changes to Page view, but that’s not true – viewing a layout in Write mode Galley view and switching to Engrave and back puts you back in Galley view.
I can’t work out the rules here, might be unintended.
Thanks! I’m glad I’m not crazy, that’s important. Can I adress this somewhere, so it might be corrected in future updates?
I think you just did! The devs team reads everything in the forum, so they will see this conversation.
This is definitely something that’s bugged me as well. A common method to avoid the above scenario (especially in the engraving stage) is to have a second Dorico window open with the full score permanently in Write mode / Galley view, as switching between windows is quicker and more reliable. A second monitor is a big help here too, if you have one.
