Accent position doesn't save

Dorico
#1

I’m working on a rather long piece that is partially an XML import from Finale (voices imported, piano reduction in Dorico), and have run into a problem that the Articulations/Articulations of force/Placement checkbox in Properties will not always save with the file. In many bars I can check the box, specify Stem Side (4 voices) and it will appear fine on screen. If I save the file, close it, then reopen, that property hasn’t actually saved and they are back to the incorrect side. Removing and re-entering the accents doesn’t make any difference either, they still will appear correctly on screen, but upon saving, closing, and reopening they are back to the incorrect side. The only way I can be sure they will save is if I delete the notes and re-input the notes and the accents.

Has anyone run into this before? It’s making me nervous that possibly other edits aren’t saving correctly either. It’s not my composition so I can’t post it publicly, but could email it if need be. Thanks for any advice.

#2

Presumably you would only need to attach an affected measure or two that displayed the problem, and that would give you more eyes on the problem.

#3

I think I semi-solved it, but there is still a bug in that what is displaying on screen is not being saved. I was just clicking the toggle as clicking it reset the position visually, but doesn’t actually save. If I go into the drop-down and actually select Stem side then the setting would actually save. There is a difference as to what appears on screen and what saves when I just click the toggle rather than going into the drop-down

I can’t seem to post a cut-down file because the file is too large. Is there a way to make Dorico purge deleted data from a file?

#4

Try setting the Playback Tempate to Silence.

#5

I did and it’s still almost 6 megs. I cut it down to 2 offending bars in one flow, but the file was originally 8 movements (8 flows) so the file size is still very large. Even if I just try to export the flow it’s still that size. Is there any other way to have Dorico purge the deleted info from the file?

#6

Ok, I’ve figured out how to reproduce it in a clean file but it’s a bit involved:

  1. Create the following file in a program other than Dorico, and export it as XML. I used Finale, but I’m curious if it works coming from other programs as well.

  1. Import it into Dorico with Preferences/MusicXML Import set to preserve stem directions and articulation placement.
  2. Add a piano.
  3. Copy or Alt-click the Soprano into the right hand.
  4. Copy the Alto and Paste Special/Paste Into Voice/New Downstem Voice into the right hand as well.
  5. Since we preserved stem directions the stems are all wrong for a piano reduction, so flip all the stems in the right hand.
  6. Now the accents are colliding because we froze the articulation placement too. Select all the notes in the right hand and click the Placement toggle in the Properties panel under Articulations of force. Note that it is impossible to clear the toggle to a default state if you’ve selected articulation placement on XML import, but they will flip anyway and now appear correctly as below:

  1. Save the file and close it.
  2. Open the file you just saved. The accent position is colliding even though it appeared correctly on screen in the file you just saved.

Can anyone else reproduce this? It was pretty scary to have spent a bunch of time fixing these, only to find they didn’t save at all when I opened the file. Normally in a non-XML flie, just clicking the toggle restores it to a default state, so I was assuming that was happening as that is what appeared on screen. I didn’t realize I had to actually go into the drop-down or it wouldn’t save with the file. This is dangerous, and I almost sent a PDF off with a ton of these collisions because I had previously made a pass and fixed them all. What appears visually on screen really needs to save with the file.

#7

Actually I just realized the XML does not need to be from a program other than Dorico. You can use Dorico to create step 1 above and still get the same results upon XML import. Following steps 2 through 9 still results in the saved file not matching what was displayed on screen before save and close.

#8

Confirmed…

#9

Thanks for confirming. This bug cost me a lot of time yesterday as I had to make the edits twice (since the first pass at these didn’t actually save) and then had to re-proofread everything as I wasn’t sure at the time what was going on with the file. Ugh! I hope the Dorico team can reproduce this too and can address it in a maintenance release.

#10

This is unfortunately not an uncommon problem with MusicXML import. I suggest you switch off the ‘Articulation placement’ option on the MusicXML Import page of Preferences to avoid running into this in future. In fact, in general I would advise switching off as many of the checkboxes on the MusicXML Import page of Preferences as you can, since that will give you musical data that is as close as possible to what you would end up with if you simply entered the music in Dorico yourself.

A bit more explanation as to why this happens: when Dorico imports MusicXML, all of the forced placement information has to be mapped onto properties. At the time at which the properties are set, no layouts exist, so properties that would normally be set in a layout-specific way (such as articulation or slur placement) are instead set globally. The Properties panel doesn’t work correctly with properties that are set with a scope other than the one that is normally set in the program, so although it looks like you can unset such a property using the panel, in fact you can’t, because Dorico will only try to unset the property with the normal expected scope, rather than the global scope with which the property has been set.

The only way to be sure of removing these properties is to use Edit > Reset Appearance or Reset Position, as appropriate for the property in question. Or, better still, don’t import the overrides in the first place from the MusicXML file.

#11

Thanks for the explanation. The layout vs global situation makes sense. The problem is I have no recollection of what has been manually adjusted in most previous files. This example was from a large project two years ago (full score is 152 pages), so I definitely don’t recall all the manual adjustments, and I’m sure with any long vocal piece there are going to be many times when articulations or slurs have been manually flipped. I need the staves to import matching the conductor score exactly, so not knowing what I’ve adjusted manually, I really have it import with those settings set to be sure they are preserved, or else I have a ton more work proofreading against the conductor score.

If Dorico can’t properly adjust the property of an imported item when the toggle is unchecked, I would suggest it either a) does nothing, b) gives the user a property “out of range” error, or c) just resets appearance or position. Having it reset the appearance is probably most desirable, because that is generally what the user wants when they are unchecking a property, but either of the other two would be preferable to misleading the user that something is being changed when it is only temporary until the file is closed. The current solution of changing it temporarily is really dangerous as it is too easy for a user to send something off for publication without realizing the property hasn’t actually been changed.

Just my $0.02, but I would really like to see the current action changed to something safer.

#12

It’s certainly not an ideal situation. Don’t infer from my response that we think we should leave it that way indefinitely.