I am making a new forum for this because it hasn’t been raised yet with Dorico 3.5 but the glitch seems to have not been fixed yet. When I switch from Galley view to Engrave mode, the selection is very often not in view or at some weird edge of the page. (I tried to include a video but the forum wouldn’t let me).
Can’t you just make the position of the selected element the same between Write and Engrave regardless of mode or zoom? That seems like a relatively doable fix and would be intuitive. I use a lot of lines and formatting in my pieces, and I need to edit them as I write or I won’t remember what they mean but I like Galley view and don’t want to have to use Page view in Write all the time. This issue seems like a simple fix but right now the glitch ruins my writing process in the software.
I understand your frustration regarding this issue, but this is your fourth post in the past half-hour or so.
The Dorico team reads and considers every forum post, as do many of the power users here. Please read over the community guidelines, and don’t post repeatedly about the same issue. Thanks.
It’s a well known issue, and I’ve personally wasted a ton of time looking for the selection as well. If you have a large score the fastest solution IMO is to just hit P (for playback) after switching views. The playback cursor will jump to your selected item so it’s in view. Then hit P again to stop playback and resume work. For me this is usually faster than hunting around for the selected element.
It’s apparently not or it would have been fixed already.
One way to minimise the chance of this problem occurring is to use page view in both Write and Engrave modes, so that switching modes only needs to change the window furniture and not switch view type. Even if the selected item reliably remains in view, it will always be a bit disorientating to switch between galley view and page view, so if you are at the point where you are switching frequently between Write and Engrave modes, you are presumably doing some of the finer layout and graphical adjustments required to finesse your finished pages, in which case being in page view in Write mode will definitely help.
The other potential issue is that if you are using one of the ‘Fit…’ zoom levels, like fit page height or fit page width, switching between Write and Engrave modes can also change the size of the viewport in which the music is displayed, because you may have different panels/zones opened or closed in each mode, and in any case the dimensions of the panels/zones are different between the modes. This means that the viewport may be a different size, causing Dorico to have to recalculate the zoom level when you switch modes, and it can then make an incorrect decision about which page you want or expect to be in view.
Having said all this, I agree with everybody who finds this issue with bringing the selection into view problematic. The next version of Dorico will improve things in a couple of specific ways, but to fix these problems, we need reproducible cases to investigate. Since window geometry and the specifics of the selections being made, including the precise position of those selections on the screen, are significant factors in the behaviour, we need a detailed bug report, including the project itself, screenshots of the whole display (not just a part of the Dorico window) before and after the jump, and a detailed description of the specific steps you took.
As requested, here’s an example project, as well as a gif. I selected the G in the middle of the screen, hit Ctrl+Alt+2 to switch to Galley and it’s nowhere to be found. I press P and the screen and playback cursor jump to the hidden selection.
(I actually messed up and hit Ctrl+Alt+1 first because I never seem to get that shortcut correct. A single “Toggle Write View” shortcut to switch back and forth between Galley and Page would be a very welcome feature for me anyway)
Thanks for this case, which I’ve spent a few hours looking into this morning. I think there are two things going on here.
One is that Dorico is always trying to move the view to the bar in the centre of the view, regardless of whether or not you have something selected, and I think that’s unhelpful – I think it should only do that in the event that you don’t have anything selected.
The second thing is that Dorico is calculating the correct offset to bring the selected item into view at the left-hand side of the view (so that you can see as much of the following music as possible; it does this because it doesn’t differentiate between moving the view when you’re e.g. editing or navigating through music in galley view versus calculating the initial position when switching to galley view)… but that offset is not correctly being applied, because due to the complex notifications that get fired off when you switch between view types, it’s asking the view to move to a position before it has finished calculating the final dimensions of the view.
So we should be able to fix this case in the next version, such that if you have an existing selection and you switch to galley view, Dorico will try to bring that selection into view at the left-hand edge of the view, and it should work reliably.
I can also confirm that we have already implemented a command to toggle between page and galley view with a single shortcut, and it will be included in the next version. (It’s very likely already included in the iPad version, as Window > Toggle View Type in Key Commands.)
This is great news thanks! I’m not sure if this is the same calculation or not, but here’s another jumping gif demonstrating something that happens to me all the time. I typically leave Engraving Options/Text/Position of text to “Use default position” instead of avoid collisions just to prevent vertical spacing issues (especially with rehearsal letters). With a json hack I have a shortcut for Avoid Collisions that I can easily invoke whenever I want to use it. If I have text where I know I want to use Avoid Collisions a typical workflow might be 1) input text, 2) Ctrl+3 to switch to Engrave, 3) Shift+Alt+V (for aVoid), 4) Ctrl+2 to go back to Write. It only takes a second but usually I end up with something like this:
I start with bar 6 as my leftmost measure in Galley, have a selected item in bar 9, but by the time I’m back in Galley a second later, bar 36 is my leftmost measure and my selected item is nowhere to be seen. As long as my text item remains selected, do you think it will still be visible after switching to Engrave and back in the next version?
Also, I have no idea if these observations are relevant or not, but examining that gif frame by frame leads to a few interesting points.
Ctrl+3 seems to briefly switch to Page View Write mode for a few milliseconds before actually switching to Engrave mode:
I obviously don’t know what causes the jump away or if that’s the same calculation you are referring to, but it would be great if that could be eliminated.
Probably not relevant, but it is odd to very briefly see Engrave mode Galley view on the switch back:
It’s interesting to note that the “Engrave mode Galley” correctly has my selection at the exact same location where I initially started with bar 6 as the leftmost bar. This is great! … until Dorico unnecessarily jumps ahead when Write mode is activated:
It’s this jump that is particularly frustrating for the user, because Dorico seemingly “knows” the correct view, and jumps unnecessarily to the wrong spot. If this is the calculation you have changed, this would definitely be a big timesaver for me!
I’ve spent several more hours looking at this more complex case, and I’ve made some headway. When you switch mode, a whole series of notifications is fired off, various bits of the application being told that the view type is changing, the size of the viewport is changing, panels are being replaced and thus resized, and so on. Midway through this series of notifications, the class responsible for determining the position of the score in the view is informed of the position of the selection, and brings it into view; but subsequent notifications end up overriding this decision. This is why you (frustratingly!) see the selection in view for a moment before it is snatched away again.
The good news is that I think we’ll be able to improve this in the next version, subject to the fix passing muster with our testing department, such that the selection will end up in view after the mode switch is complete.
