I’ve run into two issues on a recent project where copy/paste behavior was unexpectedly wrong. In both cases it turns out that notation/engraving settings I had turned on affected the behavior of the copy/paste, when the underlying music was the same.
Note that I am still on 1.2.10.136.
I’m attaching links to workflows that reproduce the issue.
The first case involves copying tuplets. If I turn on the Engraving Option to suppress repeated tuplet brackets, then any tuplet where the bracket is suppressed is copy/pasted as if it were not a tuplet at all. I’ll post the second case in a second message on this thread.
The second issue has to do with overlapping noteheads. If I have the Notation Option turned on to allow half notes to overlap shorter notes, and then copy/paste bars where the overlap occurs, I lose the note that was overlapped.
Neither of these issues are dealbreakers, but they seemed related, and the behavior is definitely unexpected. I noticed at least the second one also reproduces if I select the bar and use ‘R’ instead of copy/paste to replicate it.
Seems this is meant to be a “feature” …
I was grumbling against it for a while Tuplet problem - Dorico - Steinberg Forums
but with the new enhanced paste features I get along…
To summarise: Dorico only selects things that are visible. As such you can only copy and paste things that are visible. If a tuplet bracket is hidden, and the signpost isn’t visible, you can’t select it, so you can’t copy it. Same goes for overlapping noteheads. Interestingly, if you drag a marquee selection (that encompasses the stems of both voices) the overlapping notes get copied; at least in my (more recent) version of Dorico.
I could see that explanation, but if I click on the bar itself (clicking outside of any specific object), it should select everything in that bar. The fact that a marquee selection does catch the extra note is interesting.
I intellectually understand what you are saying, but feel it is very counterintuitive, especially in the second example where even if the notehead is not shown, the stem is, and so selecting the entire bar and replicating it feels like it is clearly missing something.
But it seems this has been argued before, so I won’t go to the mat on it. If you ever decide to re-evaluate this, count my vote against the current implementation, and in favor of including even items hidden by notation/engraving settings.
I have to admit to being with Giles on this. Even if not using normal Copy technique (Ctrl/Cmd-C) perhaps via an extended copy (Alt-Ctrl/Cmd-C) which copies everything in a bar or attached to a selection.
PS: What are these enhance paste functions that Tagaluche refers to? I’m on 2.1.20 and don’t see anything new…
Dear Beechside,
There are indeed some new functions since the thread he refers to. The “tuplefying” thing appeared in Dorico 2.1 and the paste into voice… and other duplicate to staff below/above (through context menu or Edit menu) in Dorico 2. You probably know them, but felt it could be useful to remind those for users who do not read the forum too often
I ran into this problem myself, and was massively confused as a new user, because someone had hidden some triplets so that they were not visible in subsequent measures, and with signposts disabled, the triplets then were destroyed on copy and paste.
I’m told that by default, signposts are enabled, and this should not happen. I am fairly certain that in the roughly two minutes I spent with Dorico before opening this file, I didn’t even discover the signpost menu item, yet all signposts were hidden for me.
Perhaps this setting is per-file, in which case the confusion is because the person who notated this turned them off, but if I’m wrong and I did turn it off in that brief period when I tried the demo half a year ago, then that makes this design decision even more troubling, because it means that something in the way the UI is designed is visually distracting enough to make new users do something that results in seriously unexpected behavior in the future.
While I can understand the desire to filter copying and not copy some subset of items (particularly lyrics), there are at least four problems with filtering copy/paste in this way:
The resulting behavior is nonsensical. In the current design, it’s literally always a mistake to copy music with triplet signposts disabled, to within the margin of error.
The first rule of UI design is to make common things easy and uncommon things possible. This makes extremely uncommon things (copying while removing triplets) easy and common things (exact copy and paste) hard. Even if you’re aware of the design, this adds extra mandatory menu bar steps to an action that is very, very common (copying and pasting), and you don’t discover the error until you paste, at which point you have to go back and re-select the content and redo the copy operation, which wastes time. And if you’re not aware of the behavior, it’s insanely confusing, as described in the next bullet.
It is a side effect that is not readily discoverable. Most people are likely to turn off signposts because they find them distracting, and this is likely to occur when they are not about to copy and paste content. As a result, they might not see the unexpected side effect until days, weeks, or even months later, which means the connection between cause and effect is not intuitively obvious.
The design fundamentally conflates views with data models. Choosing to not show things in the view layer should not cause changes in the way the model behaves, yet that’s effectively what’s happening here; part of the data model is being destroyed during a routine operation because of how the view’s visibility settings are configured. So this is basically an MVC layering leak designed into the UI.
IMO, Finale’s copy/paste filter was a much more correct UI approach, because it properly separates visibility (the view) from behavior (the model). You might still get wrong results after a period of time, but at least you’re not going to be too surprised, because you knew that the setting was explicitly about copying back when you changed it.
But I’d settle for a warning dialog to keep from wasting so much time and causing new user confusion: “Warning: You are copying content with signposts disabled. Hidden items may not be copied correctly.” This has the advantage of immediately alerting the user to the fact that signposts are disabled at a time when it is actionable — during the copying process — rather than deferring that realization until after the selection has been destroyed and the user is pasting the content somewhere else. It also has the advantage of quickly tying the cause — signposts being disabled — to the effect — content being missing on paste.
But I still question whether copying music with tuplets disabled should even be possible, as it is all but guaranteed to be a mistake unless you’re taking an entire measure that is filled with nothing but tuples and pasting it into something with a different time signature and a triplet feel, and that might happen for the average composer once per lifetime, if that.
So I’d like to once again urge the Dorico folks to rethink this design. It’s still confusing to new users almost a decade later, and it has the potential to be an ongoing source of friction.
Only if you have triplet numbers hidden. If you want to copy triplets, you need to select either the triplet number itself or the signpost.
For the rest of your points, Dorico is pretty consistent about the fact that it will only copy things that are actually selected. In the specific case of tuplets, the tuplet is a separate object from the notes in the tuplet, so one way or another you have to have it selected in order to copy it. I agree that most commonly you’re going to want to copy the tuplet along with the notes, but it would seem inconsistent in this case to implicitly select the hidden tuplet.
This is an interesting user behavior issue. The whole point of signposts is to let you know that something is in the score that’s not visible. Personally, I only turn off signposts in the late stages of layout, if a page is cluttered with them and I want to focus on the underlying content. You might be interested to see how many forum posts there are from users who don’t understand why things are interacting in a certain way, and when they are advised to turn signposts on it becomes clear that there’s a system break there, or a visibility change, or a bracket change (or a tuplet!). That’s why signposts are on by default, and the general advice you’ll find on the forum is to leave them on.
I like that idea, but only if the warning has a “Don’t show again” checkbox. It would help clue users in to the principle that Dorico only copies items which are selected.
Totally. That’s literally the whole point of that sort of UI.
Fair.
To be clear, I’m just assuming that the reason people turn them off is that they found things distracting, based on another thread where someone suggested that a lot of folks turn it off way too early in the process and end up confused. I have no idea why it was off in this file, as I did not create the file initially.
Architecturally, it’s a separate object, but in terms of the way the user perceives it, it is also a fundamental aspect of the notes themselves, which makes it meaningfully different from other objects.
If you select a range of notes without articulations, you’ve lost the articulations. If you select a range of notes without lyrics, you’ve lost the lyrics. If you select a range of notes without the tuplets, you’ve lost the notes themselves, as it would take a Herculean effort to reconstruct the original rhythm at that point. You’ve changed the duration and/or position of potentially every note in the selection, and the result is now gibberish.
To be fair, it’s way worse because Dorico automatically rebars the measures, or else you could just re-add the tuplets, but I’m not sure that disabling that behavior would really be enough of an improvement to not be annoying.
That said, I would argue that the current selection behavior is wrong across the board, whether you’re talking about tuplets or any other signpost. Dorico already provides an easy way to unselect undesired elements before copying, so in the unlikely event that someone really does want to not copy tuplets (or anything else), they can easily achieve that by filtering the selection.
What’s missing is selection of all signposts in a region by default until unselected. As a result, Dorico provides only three out of four possible behaviors, depending on selected options:
item is visible and copied (default)
Item is visible and not copied (filters)
Item is hidden and not copied (signposts hidden, or signposts hidden with filters)
and the fourth combination is entirely missing:
Hidden and copied
except in the rare case when you need to copy every stave at once (system track).
And the only reason the fourth behavior doesn’t exist is because Dorico is making a single setting do two things. Those items are tied to a note that is being copied, so I’m assuming that it wouldn’t be hard for the signposts/articulations/tuplets/dynamics/* associated with that note to be selected by default when those notes are selected, then let the user explicitly unselect them if desired. And with that one tiny change, suddenly you get full access to all four of the possible behaviors instead of just three.
And if you really want persistence, just make the filters be check marks that you turn on or off, rather than actions on the current selection. That way, every time you select something, if the tuplet selection option is unchecked for some bizarre reason, it doesn’t get selected/copied. There’s no reason for the signpost visibility submenu to be the UI element that gates selection behavior when there’s already a perfectly good selection-specific filter submenu just one menu over.
Sadly, this isn’t the only thing that has seriously caused me headaches. Yesterday, I suddenly realized that several dozen undos back, an entire staff got all of the note durations changed to sixteenth notes. Presumably I clicked a note duration button, not realizing that there were notes selected.
And today, somehow, while transposing a few measures of a score by an octave, I discovered much later that the entire flow had been transposed up an octave (dozens of undos earlier, presumably). I have no idea how that one happened, so I’m going to have to spend some time and figure out how to reproduce that behavior so that I know what never to do again. If anybody has any ideas of how that could happen accidentally, let me know.
I know this is all at least in part user error (though there are definitely design aspects that make such catastrophic user errors way easier than they probably should be), and presumably I’ll make fewer serious mistakes as I learn where all the sharp edges are, but it has definitely been a traumatic couple of days.
Anyway, just wanted to those thoughts out before I fall asleep at the keyboard.
This is by design, and I suspect that it’s not likely to be changed. And while it may be frustrating at times, it’s also consistent: If it’s not visible, it can’t be selected, and if it’s not selected, it can’t be copied.
Since the system track selects every staff in the current layout, you can use it to work with a single player by first switching to that player’s layout.
I get this perspective, and I don’t disagree, at least not in terms of general musical perception. And I was also initially tripped up by Dorico’s behavior with tuplets. But once I saw the logic behind the behavior, it made sense and was easy to remember. I think that happens with lots of software: You do something and get an unexpected result, and then you figure out why and don’t do it again.
FWIW, articulations in Dorico are a property of the note; you can’t copy a note without its articulations. And dynamics are attached to rhythmic positions, not notes.
If anybody has any ideas of how that could happen accidentally, let me know.