If I understand correctly, you are observing that when importing MusicXML files containing manual positioning info, this info is ignored. This is indeed true, has always been so as far as I recall. The problem is that different programs have different default positining, so manual adjustments that make sense in one program usually won't in another. So it is generally better to ignore it on import. That said, there might be specific cases where it makes sense. As it is, we don't know which elements (some particular slurs?) in this particular file you might have happened to want to see preserved, or what leads you to think that manual adjustments made in Finale would continue to make sense in MuseScore. Can you explain further?
The Problem is, that manual adjustments (slurs) done after import jump back to auto placement, which is an incorrect position, as you can see in the videos. This happens by saving the score or while working on other objects.
What really helps the most is an actual score (I am assuming the MusicXML file you attached is intended to be that) and a precise series of step of instructions written out that we can follow to see if the results are as expected or not. As I said above, it is indeed normal and expected that manual positioning present in MusicXML files is ignored on impo9rt, because there is very little chance it would end up being relevant (a slur that you moved upward in Finale by 1mm, relative to what? the default in MuseScore is surely different, so that same 1mm adjustment might be totally wrong)
It's not a Problem of import, as you write , it's the workaround after.
You can't reproduce it?
Open the XML score and mark the slurs that are obviously too far from notehead.
Deactivate "Automatic Placement" and activate "Offset", original/default settings. The slurs are now psitioned correctly.
a) Save the score, now the adjusted slurs jump back and are saved in the original position (automatic placement), which is too far from notehead.
b) Set a repeat mark in a measure with an adjusted slur, and the slur jump back to the original position (automatic placement), which is too far from notehead.
The same thing happens with other scores, if you have adjusted slurs.
Request for manual positioning info in MusicXML files to be preserved
⇒
Automatic placement setting reverts on save/reload of specific score
Ah, so you are saying this is not about MusicXML import, but about something that happens while saving a score? I am unable to reproduce a problem immediately on saving, but I can if I then close the score and open the saved version. So let me verify this is what you mean:
1) open the MusicXML file attached in this thread
2) click the last slur of the first measure
3) turn off automatic placement
4) drag slur elsewhere
5) save score (giving it a new name of course because you can't save directly as MusicXML)
6) close score
7) open the score saved at step 5
Result: slur has reverted to automatic placement. Not sure why, and I can't reproduce this in a score I create from scratch, but this much at least I can confirm.
I don't understand your point b about "repeat mark", not sure what this is. I tried adding a start repeat barlien to that first measure, also a coda sing, neither produced any sort of problem in themselves. Could you give a similarly step-by-step produce to reproduce the problem you seeing there, if it differs from the more problem with save / reload?
1) open the MusicXML file attached in this thread
2) click the last slur of the first measure
3) turn off automatic placement
4) drag slur elsewhere
5) add a repeat barline to that first measure
Result: slur jumps back to the position of automatic placement.
1) open a new file (4/4)
2) enter five quarter notes and a slur above the notes
3) turn off automatic placement
4) drag slur elsewhere
5) add a repeat barline to the second measure
Resut: slur jumps back to the position of automatic placement.
But - is there an actual problem? I still don't see a clear statement with score & steps. I suspect whatever problem may have existed at one point during development it was fixed long ago.
Comments
This is very vague. Can you give examples of what you are talking about and instructions on how to reproduce the issue?
In reply to (No subject) by geetar
It's mainly about slurs. I'm opening XML in these examples below:
https://schulethalch-my.sharepoint.com/:v:/r/personal/leo_schnoz_schule…
https://schulethalch-my.sharepoint.com/:v:/r/personal/leo_schnoz_schule…
In reply to It's mainly about slurs. I'm… by carax
I,m sorry, now the links should be o.k.
https://www.dropbox.com/s/qk8axdvrk7jr2gu/MuseScore%203%20%283.0.0%20un…
https://www.dropbox.com/s/pfe69p5ae90r951/MuseScore%203%20%283.0.0%20un…
Better attach these directly here, esp. the XMLs
In reply to Better attach these directly… by Jojo-Schmitz
If I understand correctly, you are observing that when importing MusicXML files containing manual positioning info, this info is ignored. This is indeed true, has always been so as far as I recall. The problem is that different programs have different default positining, so manual adjustments that make sense in one program usually won't in another. So it is generally better to ignore it on import. That said, there might be specific cases where it makes sense. As it is, we don't know which elements (some particular slurs?) in this particular file you might have happened to want to see preserved, or what leads you to think that manual adjustments made in Finale would continue to make sense in MuseScore. Can you explain further?
See also #19459: [MusicXML] element offset handled incorrectly
In reply to See also #19459: [MusicXML]… by Marc Sabatella
The Problem is, that manual adjustments (slurs) done after import jump back to auto placement, which is an incorrect position, as you can see in the videos. This happens by saving the score or while working on other objects.
What really helps the most is an actual score (I am assuming the MusicXML file you attached is intended to be that) and a precise series of step of instructions written out that we can follow to see if the results are as expected or not. As I said above, it is indeed normal and expected that manual positioning present in MusicXML files is ignored on impo9rt, because there is very little chance it would end up being relevant (a slur that you moved upward in Finale by 1mm, relative to what? the default in MuseScore is surely different, so that same 1mm adjustment might be totally wrong)
In reply to What really helps the most… by Marc Sabatella
It's not a Problem of import, as you write , it's the workaround after.
You can't reproduce it?
Open the XML score and mark the slurs that are obviously too far from notehead.
Deactivate "Automatic Placement" and activate "Offset", original/default settings. The slurs are now psitioned correctly.
a) Save the score, now the adjusted slurs jump back and are saved in the original position (automatic placement), which is too far from notehead.
b) Set a repeat mark in a measure with an adjusted slur, and the slur jump back to the original position (automatic placement), which is too far from notehead.
The same thing happens with other scores, if you have adjusted slurs.
Ah, so you are saying this is not about MusicXML import, but about something that happens while saving a score? I am unable to reproduce a problem immediately on saving, but I can if I then close the score and open the saved version. So let me verify this is what you mean:
1) open the MusicXML file attached in this thread
2) click the last slur of the first measure
3) turn off automatic placement
4) drag slur elsewhere
5) save score (giving it a new name of course because you can't save directly as MusicXML)
6) close score
7) open the score saved at step 5
Result: slur has reverted to automatic placement. Not sure why, and I can't reproduce this in a score I create from scratch, but this much at least I can confirm.
I don't understand your point b about "repeat mark", not sure what this is. I tried adding a start repeat barlien to that first measure, also a coda sing, neither produced any sort of problem in themselves. Could you give a similarly step-by-step produce to reproduce the problem you seeing there, if it differs from the more problem with save / reload?
In reply to (No subject) by Marc Sabatella
1) open the MusicXML file attached in this thread
2) click the last slur of the first measure
3) turn off automatic placement
4) drag slur elsewhere
5) add a repeat barline to that first measure
Result: slur jumps back to the position of automatic placement.
https://www.dropbox.com/s/i6xikyvlforzhbk/MuseScore%203%20%283.0.0%20un…
1) open a new file (4/4)
2) enter five quarter notes and a slur above the notes
3) turn off automatic placement
4) drag slur elsewhere
5) add a repeat barline to the second measure
Resut: slur jumps back to the position of automatic placement.
https://www.dropbox.com/s/8mus1w2cvezzgi2/MuseScore%203%20%283.0.0%20un…
Your descriptions are clear, but I cannot reproduce - nothing goes wrong for me. Can anyone else? What does Help / About say for you?
In reply to (No subject) by Marc Sabatella
It's strange, I tested it on 3 different devices, with the same results as described and shown in the 2 videos above.
Can you please verify which build you are using, and try the latest if yours is older than a few days?
In reply to Can you please verify which… by Marc Sabatella
I always use the newest build and fortunately the build of today solves the problem.
All of the problems, including the problem on save/reload, or just the problem where it jumps immediately?
In reply to All of the problems,… by Marc Sabatella
Only the problem on reload isn't yet solved.
In reply to Only the problem on reload… by carax
I found the same problem on reload concerning hairpins, maybe there are more.
But - is there an actual problem? I still don't see a clear statement with score & steps. I suspect whatever problem may have existed at one point during development it was fixed long ago.