Engrave mode allows you to manipulate and modify every item in your project, but without deleting them, moving them rhythmically, or changing the pitch of notes. You can also determine how the pages in each layout of your project are formatted for printing or exporting.
The idea of a separate, editable presentation layer is excellent. Ideally, as the manual suggests, you should be able to click and select any element consistently, then move, scale, rotate, or change its color and opacity.
That is not how Engrave mode actually works though. It does not handle “every” item in a consistent or intuitive way. Some elements cannot be adjusted at all, and others use different selection methods just to reveal the relevant properties in the lower panel.
Want to move an articulation horizontally? You can’t. Want to move a system divider? No luck. Apparently, it is not even treated as a real item. Click on a beam to access beam properties? No — you are expected to click the notehead instead. Want to adjust beam angles with Option + arrows? That works as expected. Want to do the same with an augmentation dot? No — again, you have to click the notehead. Want to move staves? First switch the Engrave sub-mode.
And these are only a few examples. My point is simple: the way different elements are handled in Engrave mode is inconsistent and unintuitive, and that inconsistency points to a fundamental design flaw. At this point, it is long overdue for a serious rethink.
When it comes to things like articulations, beams, and augmentation dots, the reason they behave differently to other items is that they are not themselves independent items, but are fragments of notes/chords. It would indeed be better if these fragments could be treated exactly like independent items, but it’s difficult to achieve. That doesn’t indicate a fundamental design flaw, as you assert.
What it indicates is that there is a limited number of people working on Dorico with limited time, and that we have chosen to focus our limited people and time in other areas. It would of course be possible, given sufficient time and attention, to make it possible to nudge rhythm dots and articulations with Alt+arrow keys. It has simply not yet been implemented.
The choice to use “sub-modes” in Engrave mode to adjust vertical and horizontal spacing, or indeed music and text frames, is likewise not indicative of a fundamental design flaw, rather a design choice. You don’t have to agree with our design choices, of course, and we are always interested in feedback from our users about how we can make working with our software more efficient and enjoyable.
I apologize if the term “design flaw” sounded harsh. I did not mean it disrespectfully.
What I mean is this: if a design choice leads to inconsistent behavior, and that inconsistency is difficult to improve because of how the system is structured, then that points to a flaw in the design.
Users naturally perceive musical symbols as distinct elements. If something has its own name and function, it is understood as its own object, regardless of whether it is technically subordinate to something else. A beam may be part of a note, but it is still also a beam. A wheel may be part of a car, but it is still a wheel. There is no contradiction between something being dependent in structure and independent in identity.
That is why this feels like more than a missing feature. When the user cannot interact with a beam, dot, or articulation as an element in its own right, the software’s internal model is diverging from the way notation is actually understood and edited.
And that is also why the explanation about dependent elements requiring extra engineering effort is revealing. It suggests that there is no consistent presentation layer in which every visible notation element exists as a selectable, editable object after the notation has already been calculated. In practical terms, this would be an output-level offset or transform layer applied after all semantic and rule-based calculations are done, but before the result is shown on screen or sent to print.
Or perhaps that is a misconception. Programs evolve; they do not spring fully formed from the head of Zeus, although if any team could pull that off, I’d bet on this one.
You clearly have you own mental model about consistency. But all programs have their limitations and need to balance usability for the majority (including novices and experienced users) with flexibility for those with a niche requirement.
In this regard, I think, Dorico strikes a very good balance. There are far more parameters available to control than most users will ever need to manipulate. Indeed the bulk of this forum is filled with queries from users who have yet to come to terms with this level of complexity.
Fundamentally Dorico bridges two aspects of the “modern notation world”: what does a notation mean sonically? and what does it look like on the page (both score and parts)? That is no simple trick to pull off and it does so (IMHO) quite elegantly.
Of course it is not perfect, and will develop over time. But to suggest it started from the wrong premise is frankly absurd.
That doesn’t alter the reality that you can only speak for yourself. Others may, or may, not agree with you. Since I do not “naturally perceive” what you suggest, and I am a member of the class of Users, your statement is unreasonable.
(Further reinforced by your need to rely on ChatGPT for your argument)
