I know there have been previous threads related to this but not for a while. I noticed that in Dorico 4 there is a significant performance increase for me switching between modes which is absolutely
fantastic!
Also for the first time for me, when switching between modes and nothing is selected the view stays where it is. However when anything is selected the view jumps over and back. I attached a video of the behaviour. I can see it is seems to be due to the side panels loading. I switch between Write and Engrave mode almost constantly in my workflow, as I am sure many others might. The visual glitch really adds up over time and becomes extremely fatiguing actually. Remembering to unselect before switching is too tricky also as the changing between modes is instinctual at this stage, as well as the problem with zooming out while having nothing selected; the score goes to the start (as covered in other threads).
Is there something I can do now to fix this? If not I would recommend if possible that this might be a relatively higher priority issue than it might seem. It does seem to really add to overall fatigue in a session.
I believe the intention is to leave the scroll position where it is with no selection, but to keep a selection more or less centered in the viewport. Of course such a short system as in this video wonāt fully center anyway, in either view.
There arenāt any settings youāre missing to affect this scrolling behavior.
Please donāt bump threads on this forum. Iām sorry nobody answered you for 4Ā½ months. Since the release of 4.0 there have been fires to put out every day, and this issue would seem to be pretty far down the list (speaking from the perspective of a user who reads this forum daily).
Really? Thereās even a keyboard shortcut for it. FWIW I do not find the changing positions particularly disorienting or inconvenient. A bigger learning hump for me is, when Iāve already made a selection, getting to the wrong sub-mode in Engrave mode and having to redo the selection. But I have kept my use of Engrave mode to a minimum so far.
Sorry for not having responded to this thread sooner, Sean.
Realistically we are probably not going to try to resolve this in the immediate term. If I were to try to explain to you the complexity of what actually happens when you switch Window mode, you would be quite surprised. At this point, our plan is that we will give this whole area of the user interface an overhaul as we complete the transition to the new user interface framework that we have started to use. This should provide lots of benefits, including allowing us to use hardware GPU acceleration to draw the window and all the music, which will make the application feel faster, particularly on large displays. However, the bad news is that this rework is a big job and wonāt bear fruit in the Dorico 4.x timescale, so you will be stuck with the present behaviour for a while longer.
Thanks for replying and @Daniel, and @Mark_Johnson ,I do apologise for bumping the thread! I will refrain in the future. Thanks for the detailed explanation Daniel and yes I can appreciate the underlying complexity! The GPU acceleration and updated GUI sounds very exciting and looking forward.
Yes, really. the deselecting adds a conceptual break to a task in the moment. I understand conceptually the difference in modes and I think it is the real strength of Dorico. Having a āWriteā mode which covers the input of the visual parameters considered as music versus a mode for typesetting changes to that music is very strong and, in my opinion, undercuts the workflow time of all other typesetting softwares. The problem arises with those parameters which might fall somewhere in-between modes, conceptually; āhide stemā for example. In my experience, and I have really tried to train myself out of unnecessary switches to Engrave mode but the reality is, as a piece moves on there are more and more switching instances needed to complete one task. I think this is much less of a problem if you are typesetting material which conforms very closely to common practice music engraving. Having said this Dorico is still by far and away the best choice for the typesetting of contemporary music. Having canvassed several other Dorico users who are not forum users and are engraving contemporary music, they agree it is difficult to separate some aspects of the material input (composing) and typesetting and find themselves switching a lot also.
I do not see how the presence or absence of stems affects the desired pitch, duration , tempo, of volume of the notes entered in Write mode. Therefore, changing the appearance of the music by removing stems would presumably have a logical home in Engrave mode. YMMV.
Iām not sure I totally agree. A black notehead with a stem is a crotchet. Assuming the use of traditional notation, in general, its temporal value is determined.
A stemless black notehead is not a crotchet. Depending on context (sometimes implied as in certain religious music, otherwise maybe explicitly via performing instructions) it basically conveys a pitch with an unspecified (or maybe just relatively short) rhythm. For me, thatās a different thing to notate.
Itās obviously an āadvancedā notation, intentionally unavailable for Elements users. But itās still on the conceptual, content level of the music. I can understand why @seanodalaigh feels some frustration that features like this are in Engrave mode for no other reason than limiting their use to pro engravers, thus requiring more mode switches.
I think the distinction I am making is that (to me) the āmusicā is the sound, and that is what one enters into Write mode, whereas the stems (for example) are only a representation and therefore would quite properly fit into Engrave mode. Past notation programs have mixed these two things, which would quite naturally lead people to develop habits based on their experience.
I am not suggesting that the approaches other programs take is wrong; I just maintain there is a rationale for the way Dorico has arranged things.
(I say that as someone who even as a preteen was given Gregorian chant to read in various representations and became acquainted, although I do not claim expert, in various stemless systems.)
Thanks for elaborating @PjotrB, this is essentially what I was getting at in that specific example.
@Derrek , I understand your point, but as you describe, the āmusic as the soundā being directly equivalent to what you input in Write mode is only true in the case that the artefact being represented visually is intended as synthesised sound within the playback software. If the notation is meant for acoustic performance the result is going to stray from this very rapidly. Admitted in certain contexts not so much as to cause any difficulties, but in the specific example of a stemless notehead it might be more likely the case that MIDI playback has nothing to do with the visual representation. For example (not my approach but certainly not an uncommon approach); stemless noteheads with an affectual descriptor like āplay each note when you feel they should soundā. Which is why a stemless notehead would effect both duration and tempo.
Past notation programs have mixed these two things, which would quite naturally lead people to develop habits based on their experience.
I completely agree with this, I think I was just hitting places where there was not so clear an overlap recently, leading to my excessive switching.
I would, however, like to reverse my car slightly up the driveway on this issue in terms of workflow as I have not acknowledged how amazing the Jump bar is! It has solved many of the issues I am describing which would be under the heading āselect a thing and do something to itā. Where something might be one thing conceptually but more than one thing in terms of parameters.