I suggest a feature enhancement for Dorico: to retain the cue scale size (or other properties) for chords and lyrics after the first selection. Currently, the software defaults back to the standard scale after each entry, necessitating repeated selection of the scale for each chord or lyric. Enabling Dorico to remember the last used scale size (cue) for the duration of the single input session would streamline the workflow significantly.
Thank you for your curiosity about the use of numerous cue size elements. In the contexts I often work in, it’s not necessarily the complexity of the piece itself that dictates this need, but rather the role of the musician within the ensemble. Even when not conducting, musicians frequently need to be aware of other parts – this could include instrumental sections or vocal lines, especially in crucial passages.
Having cues at a different scale helps musicians quickly identify these important parts without overwhelming them with too much information. It’s about striking a balance between providing necessary context and maintaining readability of their own part.
I don’t have just two players. It’s a full symphonic orchestra with an added 5 element rock band and 5 singers. The full score is already done (in other softwares and not by me, not importable with musicXML) I’m redoing just the keyboard part for other reasons (which is also the musician that triggers QLab), I don’t find it useful to recreate an entire full score just to use the cue function.
I understand that the current method is workable, and indeed, I am using it. However, my suggestion aims to address what I perceive as an inconsistency in the user experience, rather than proposing a workaround. Consider this scenario: I’m inputting lyrics using Shift-L. I type the word ‘surrender’, but the software splits it into ‘sur’ in one size and ‘render’ in another. From a user’s perspective, this division seems illogical. The goal of my suggestion is to streamline the process and ensure uniformity in text sizing, enhancing the overall user experience in Dorico.
Thank you for your suggestion regarding creating a separate cue part with a uniform staff size. I appreciate the input.
However, I wasn’t aware that providing specific work context was necessary to highlight what I perceive as a logical flaw in the user experience. My intention was to address a broader usability issue in Dorico, not just a specific workaround for my current project. This issue, as I see it, affects the general workflow in Dorico and could potentially impact various users in different contexts.
I hope this clarifies my original point. The aim is to suggest an improvement that would benefit the overall functionality and user-friendliness of the software, irrespective of individual project details.
The way Dorico works currently is consistent, just from a different angle than you’re coming from: in Dorico, you either change the attributes of specific, selected, already-existing things; or you change the defaults for those things, which updates all of them.
Perhaps in your use case, where you want things to look like cues without using the cue feature already implemented in the software, you could make use of a specific type of lyric (such as a translation line), and change the formatting of the paragraph style for that type of lyric to be smaller – that way, any time you input into a translation lyric line, it will use a smaller font size than standard lyrics.
Or, wait until you’ve finished inputting, and do the formatting later?
I understand Dorico’s approach and am already utilizing the mentioned workarounds. However, my point of contention remains with certain user experience aspects, such as the inconsistent sizing in lyric inputs, exemplified in my previous ‘surrender’ example.
I know it’s not a big deal, but I find myself constantly thinking about how much better this software could be with more attention to these small details and avoiding excessively cumbersome workflows.
If Dorico’s stance is that users should adapt to these software idiosyncrasies, I’ll take note and adjust my workflow accordingly. However, this does highlight a rigidity that may not be useful in professional contexts. In environments where adaptability and intuitive user experience are crucial, this rigidity could be a key factor in why numerous composers and orchestrators sadly continue to favor Sibelius, despite its own shortcomings and flaws. In my humble opinion it’s important for notation software to evolve in user experience and workflow adaptability, not just in feature set.
I would say their position is not rigidity but simply priorities. They constantly have to decide which use cases to handle next, with a very small programming team.
I don’t know what Daniel himself will think of your idea, but you can be sure he will consider it.