Has anyone else had any problem with position offsets not sticking — or, in fact, any other properties?
I’ve experienced (at least) misbehaving tempo marks and slurs. I’ve embarrassingly handed clients work with mangled slurs not too long ago. Fortunately, this was only in proofs and it was caught before it went to print. At the time, I told myself that I was tired and that I certainly had missed those on my passes, though there were quite a few slurs where the only adjustment was on the direction and I was sure that I had corrected them before.
I’m experiencing this again, a bit severely, but now I have proof, so I feel compelled to bring this up: a scan of the score I produced a few weeks ago for corrections. The file wasn’t even opened since then; while inputting the corrections, I’m finding several objects out of their place without having been touched. Not only that, but also the tempo marks in this page have become particularly unwieldy. They jump around, refusing to align, and actually display different positions in Write and Engrave mode.
I’m gonna have another crack at it tomorrow and I’ll try to work with the limitations, but I’d like to ask whether anyone has experienced this before, and what can be done to fix it. Even if the bug behind this behavior gets fixed, can the team consider a way to really freeze certain objects, discarding them from consideration by all the spacing algorithms?
I’ve noticed this too, but not as severely as you. I haven’t had time to troubleshoot, but thought I might take a look at the Setup settings as in the attached.
Yes, this happened all the time with gradual tempo markings in my scores to the degree that I stopped using them, I have mentioned this in a post long time ago. They jumped up every time I made a change in the score aftwards, could be something as moving a hairpin or anything else. I really hope this will be fixed someday so I can close those scores.
I didn’t come across Andre’s thread because, the way I looked at it, the behavior would be the same. I was inclined to believe this is something with the position offsets, but the issue with tempo markings might be a different thing. Still, interestingly, they happen in tandem…
edit — Dorico, you rascal. Opened the file and everything was in its right place. The first edit screwed up the lines again, so I saved it, closed Dorico and opened the file again, and there they were in their best behavior. Hopefully this might save me: I’ll soldier on and make note not to export anything unless it’s from a freshly opened file.
There are certainly some problems with gradual tempos not being stable in terms of their vertical position, under some circumstances. We haven’t yet determined exactly what conditions need to exist for the problem to occur. One thing that certainly exacerbates matters is having Shift+X text items in the same kinds of positions. Once we can pin down the precise circumstances this occurs, I have no doubt we’ll be able to fix this problem.
But regarding the properties on other objects not sticking, am I the first one to complain? Because I do get the feeling that they don’t always stick, or that unnecessary recalculations (such as the ones that make the gradual tempo marks misbehave) are being triggered.
I’ve noticed properties not sticking while dealing with slurs, mostly. As I described in my first post, I’ve had trouble getting Direction and the various Position Offsets (start and end) to stick. I would fix a slur, it would be correctly displayed in Write or Engrave mode, but when I extracted a PDF it would be off. I eventually tamed all of these cases, but I don’t know what I did bar sheer persistence. Luckily I had the time to do multiple passes for corrections.
In the case of the project I’m currently working on, many slurs were different when compared against a previous printout. This right at the bat — without any changes or edits, just right after opening the file. Just opening the file yielded different results.
This might have something to do with MusicXML import, I feel.
Just a few days ago, I noticed certain slurs would pop out of place when other things were adjusted (unrelated to the anchor notes of the slur) but usually clicking on it, or adjusting one of the handles would cause it to pop back into place. That said, there were at least 5 slurs I had to deal with that changed themselves. It typically (but not always) seemed to involve when Dorico auto-adjusted the gap between a grand stave. For instance, I would have a slur in the first measure of the system, three measures later, add a dynamics marking which would cause the spacing to expand ever so slightly, and the slur in the first measure to jump out of place. Again, adjusting one of the parameters would cause it to jump back / re-render.
Certainly MusicXML import causes properties to be set differently for slurs, because unlike properties that you set, properties set during import are set globally rather than being layout-specific. If you’re going to do a lot of editing, I think you might be better off selecting the slurs and doing Reset Appearance/Position to clear the properties set on import.
I have noticed this behavior and mitigated it by ending the line slightly early, e.g. an eighth note before the barline prior to an absolute tempo marking—this in Write mode.
RE: Slurs
I have also noticed slurs not retaining properties (from-scratch Dorico projects) but that’s a whole other discussion in another thread…
From scratch? Ooh… I was seriously hoping this had to to with MusicXML import. That we could handle, I guess. After finishing this project I might have time to run some tests before coming guns a-swinging with complaints, so as not to muddy the waters. Hopefully I’ll stumble into consistent behavior.
I can back up thiagotiberio on the slur issue. I engraved and printed a piece last week. I opened it up yesterday and adjusted one thing in a measure two pages later and when I went to reprint, slurs had gone all wonky in a few measures again.
And there is is: problems with dancing gradual tempo lines on a native Dorico project. With no other objects nearby with which to align to, to make matters more confusing.
If you have a reproducible case where gradual tempo lines are moving around in an unstable fashion, please send it to me. We can’t fix bugs if we can’t reproduce them.
I know, I know. I’ll try to fashion a scenario where the behavior is reproducible. I said I would come back with something more certain in my previous post, but I plunged into another project without being able to take the time to do so when I came across the bug again.
