In my development build, this problem doesn’t occur as you describe, so hopefully this specific case will be resolved in the forthcoming update. However, it is certainly still possible to get dynamics pasting in the wrong place if your selection includes part of a dynamic group, or indeed if the destination paste overlaps with an existing dynamic group.
So this has to do with grouped dynamics — which, perhaps from some lack on my part, still seem quirky to control. Growing pains, I guess! But thank you for the ability to bind those to keyboard shortcuts!
Back to the issue, this is similar to the note input caret instantiation “issue.” Case:
Delete the notes in bar 3;
Select whole bar (which selects the rest and the mf);
Hit return to turn on note input.
I always expect the caret to be in bar 3, and not in the middle of bar 1, which has led to quite a few frustrating moments!
I know you can click on the rest to “defeat” this behavior currently, but it is much easier to click where it selects the whole bar especially at certain zoom levels. And the bottom line is: if I select a measure, I expect whatever I do to apply to that measure.
Anyway, I strongly believe Dorico’s behavior should be refined for both of these cases, perhaps teaching it to disregard the unselected dynamic items which are grouped to the selected dynamic item…
three years on with v3.5 and I have been noticing the same thing sometimes after copying larger sections. Dynamics can mysteriously pop up in the top right corner. I was considering reporting it until I found this thread. I’ll assume it’s also to do with linked dynamics as I quite frequently use them. Does that mean there has been no change to Dorico’s behaviour in this respect? Or perhaps there are now other ways (other than ungrouping dynamics) which can be applied?
Seeing as the fourth post in this thread states that that specific problem had already been dealt with in internal builds (which will now have been released and superseded by plenty of other versions), you’re clearly seeing a different problem. As always, the request is going to be that you provide a reproducible case. Please go ahead.
Daniel’s post, as I interpret it, says that when the selection includes dynamic groups then the problem can still occur, irrespective of build. Perhaps he would be kind enough to clarify himself. If indeed this issue should now be resolved then I will endeavour to provide an example of what I am seeing.
The original problem reported in this thread was indeed fixed some years ago, but if you are encountering a strange behaviour, your best bet is always to report a minimal case rather than wonder whether or not it’s already known about. Much better that a problem be reported twice than not at all.
OK, have made some progress here. The problem is easily reproducible as can be seen from a quite short passage shown in the original and copy screenshots. This occurs only if the system track is used to copy the passage. To include tempo markings and other global settings, it would seem the obvious tool for copying a substantial repeated section of the whole score. If I select first bar top left–>shift+ last bar bottom right which only copies the stave contents without tempo markings etc, then the problem does not occur.
Am I possibly misunderstanding something about the whole concept of using copy/paste effectively? The manual in the “large selections” section does include the system track among the recommended methods of selection. There is no mention of potential issues using it to copy/paste.
PS the example given is actually from the beginning of the project and pasted at the end as I was trying to establish if it’s a timing issue over a long stretch. This is not the case as can be seen in exhibit 3 where a simple four bar section is chosen and immediately repeated (selected notes show beginning of original and beginning of copy). Again it is easily seen that both hairpins and fixed dynamics have several errors.
following on from the previous post, although the time between the original and copied versions and length of copied passage seem irrelevant, the total time of the project or flow may be the deciding feature. The examples were from a 16 min. flow in a 40 minute project and I think there was a discussion somewhere about timing irregularities over longer projects. I should make it clear that I ungrouped dynamics from the entire selection before copying so that is not the issue in this case
Take in contrast the simple test project below. Although this also includes tempo changes, the copy using system track is perfectly OK.
Please have a look at the attached score. This was the much larger project discussed earlier but I deleted all but the first 17 bars. I then did the following:
selected the whole score which is 17 bars in length
ungrouped dynamics for the whole score
copied the whole score and pasted at end using system track
It can be seen that the initial hairpins and dynamics from the top line (violin 1) are completely wrong in the copy starting bar 18 though the rest seems at a glance OK.
Then look at the screenshot. I have followed exactly the same procedure but this time from the full original score. Here the same problem can be seen in the top line but by the time we reach bar 25 the cello 1 and then the violin 2 also have incorrect dynamic markings.
To me, this is fairly conclusive evidence that a) there is a problem and b) it seems to get worse as the score increases in size. It is not project specific as I have seen some similar things to varying degrees in all my Dorico projects to date. It is obviously not playback configuration specific. If these issues really have been fixed then I would invite Daniel et al to come up with an alternative explanation for what I’m seeing. If, on the other hand, it is something different then I would hope it could be investigated as such and of course I will be happy to do any further tests which might be suggested.
Incidentally, the problem is not always solved by avoiding the system track for selection as I initially thought, otherwise I guess a safe workaround would be to first copy staff contents and then system objects like tempi afterwards. copypaste test.zip (783 KB)
I’ve opened your file and i can reproduce the problem. I think it has something to do with how the system track is seeing the position of the first dynamic mark in the violin-I staff. When copying, the dynamics are displaced exactly four bars, those are the first four empty bars in the violin-I. If you, for example put a Dynamic at the first bar of the violin-I, then you can copy the passage with the system track and the dynamics will appear where expected (not that i suggest that as a solution, i’m just trying to understand what is happening there). Once you have copied, if you order the dynamics of the violin-I (move then four bars forward), you can copy again without trouble, so the problem must be at the begining of the file.
However, i tried with a couple of my files and could not reproduce the problem. And if you copy the music to a new file then copying with the system track works as expected, so i guess it is a file-specific problem.
thanks for your observations, rafaelv. It does confirm there is a problem in this particular project at least and when I paste these bars into a completely new project, the problem remains (unless I follow you suggestion of putting in a new dynamic in the first bar). I have definitely seen similar in other projects but now that I think about it, they may have all been XML Sibelius imports in Dorico 3.1 as my other native Dorico projects to date have included text so there has been no copying of long passages. xml import is certainly improved in 3.5 but I know there have been issues previously with dynamics or p.t’s not always imported to the correct place which could cause its own issues with cut and paste. If there are further issues with this particular project – which there have been – I can understand that they may not be accepted as evidence that there is a general issue.
Best is to drop it until I see clear signs in other native projects as there doesn’t seem to be evidence from others so far that this is widespread in recent Dorico versions.