Inserting bar moves clef inconsistently

• May 17, 2012 - 18:43
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
1.X
symbolsposition

Clefs are saved in a MuseScore file at two different places. This leads to a strange bug.
The places where they're saved are:

  1. In <museScore><Part><Staff><cleflist>
  2. In the bar where it occurs.

I have commented before that this is not an optimal design choice.
It indeed leads to inconsistencies, for example like this:

  1. Open a new file and add some instrument.
  2. Put a clef somewhere in the middle of the score, let's say in front of measure 9. Clef.mscx
  3. Select measure nine and push insert to insert a new bar left from measure 9. Now the clef did not visually move to measure 10, but it stayed at measure 9. If one tries to delete it, it doesn't work. Clef2.mscx

What happened? MuseScore needs to update the position of the clef in two parts of the file:

  1. It needs to change the "tick" attribute of the clef tag in the cleflist. This works perfectly. Compare lines 40 of the attached files.
  2. It needs to move the clef tag from "in front of measure 9" to "in front of measure 10". This fails. See lines 132 to 134. I suspect that the problem here is that "in front of measure 9" is saved as "at the end of measure 8".
Attachment Size
Clef.mscx 6.94 KB
Clef2.mscx 7.09 KB

Comments

• Sep 26, 2013 - 18:33

"cleflist" doesn't exist anymore. However the behavior remains that when you click on a measure with a key change just before and insert measures, the clef doesn't move. I'm not sure if this behavior is the expected one. It doesn't feel that wrong to me.

Reply

• Nov 6, 2013 - 14:16
Status (old) needs info ⇒ active

I'm testing on version 1.3, revision 5702.
@lasconic, maybe a matter of taste, but I have the feeling that a clef belongs to the bar it applies to, which is the following, not the precededing. So at least I would expect the clef to move.

Reply

• Nov 6, 2013 - 14:56
Status (old) active ⇒ needs info

Be aware that the issue tracker is really at this point only for the current development version - the builds for the eventual 2.0 release. So you should re-test on a nightly build and see if you still think the behavior feels wrong, and if you have advice on what should change, it should be based on the 2.0 file format, not the 1.3.

Fwiw, I don't find the current behavior to be a bug, at least not necessarily. If I click measure 9 and insert measures in front of it, I mostly expect those measures to be similar to the measure I started with - same key, same time signature, same clf. Yes, if the measure I started with was right on a boundary, a question arises, but I'm going to guess it's 50/50 at best as to which I might want. That is, half the time, I might want the preceeding key/meter/clef, half the time I might want the new one.

On the other hand, 2.0 seems inconsistent in this respect - I get the new clef but old key and time signature. And there also seems to be an issue with adding a meter change on a bar that also contains a key change - the key change moves to the next system...

Reply