Insert measure does not honour the time signature

I cannot confirm this behaviour for neither the current release version (1.1), nor the development ver 2.0.

This site page describes the information to provide in a bug report to increase the probabilities of locating (and possibly correcting) a bug; in great summary, telling which version are you using and, in many cases, under which operating system, as well as providing a reproductible sequence of steps leading to the error is very important.

Thanks,

M.

Confirmed bug with trunk 5395, both 3/4 and 6/8 time sigs. Win7 32-bit. All inserted and appended measures were 4/4.

See also http://musescore.org/en/node/15327

I can also confirm that this is a problem on svn r5415, tested on both Linux Mint12 (64-bit) and on Ubuntu 10.04 (32-bit). It is also more complicated than has been described so far. I started with 32 measures of 3/4, then added ~40 measures of 3/4, which worked the first time. Then added another 40 measures. Not until the addition of the second group of 40 measures did the program fail to honor the time signature. There is a simple work around though (Obviously, you need to substitute whatever time signature you are actually using for the 3/4 in the example):

1) Insert or append the measures needed plus ONE EXTRA measure. These will all be 4/4 measures and there will be NO indication that the time signature has changed. You can prove it by adding quarter notes to any of the new measures. You will be able to add 4 of them!

2) IMPORTANT!! If inserting, drop a 3/4 time signature on FIRST measure after the insertion, which will still (correctly) be a 3/4 measure. If you fail to do this, the next step will change all of your existing 3/4 measures to 4/4 and leave you with a lot of editing to undo the damage!

3)Now, drop a 4/4 time signature on the FIRST inserted/appended measure. You must do this so that the displayed time signature matches exactly what is actually there. This officially sets all the following measures to 4/4. If this is an insert, it should stop the change process when it hits the "official" 3/4 signature you installed above. If appending, all the appended measures will now be 4/4.

4) Drop a 3/4 time signature in the SECOND inserted measure. This will change the time signature of all subsequent measures to 3/4, which is what you want.

5) Select the 4/4 measure and delete the entire measure - Not just it's contents. Use the "Measure...delete selected measure" command. You will now have the correct number of added measures.

6) You should be able to delete the now redundant 3/4 time signatures, which leaves all the added measures with the correct 3/4 signature.

Note to the developers: I've attached the score that I'm working on. Hopefully this will demonstrate the problem.

As far as I can tell, the attached patch fixes the issue.

Possibly, there are still gray areas (for instance, inserting measure(s) between two frames, still gives 4/4 measures), but all the 'normal' cases I tested do work as expected.

For the core devs:

The only file changed is libmscore/edit.cpp, by adding the following lines to function Score::insertMeasure(ElementType type, MeasureBase* measure), after line 2027:

// if the MeasureBase we are adding to is a MEASURE,
// use its time sig
if(measure && measure->type() == MEASURE)
      f = (static_cast(measure))->timesig();
else {
      // if not, use previous measure time sig, if it is a MEASURE
      MeasureBase * prevMes = measure->prev();
      if(prevMes && prevMes->type() == MEASURE)
            f = (static_cast(prevMes)) ->timesig();
      // if anything fails, use default
      }


Hoping it is useful,

M.

Has the above patch been included in last trunk version ?

I got the problem with 5494.
Shall I investigate more ?

I suspect that there will be some delay before the above patch gets merged into trunk. Not because it doesn't address the issue, but because it won't compile without errors, at least on my machines. I suspect that this is due to a difference in the versions of installed libraries or some other similar thing. The point is that the developers will need to figure out the issue and fix it in a way that compiles without errors on all supported platforms/versions.

The above patch didn't find its way into the trunk code yet.

@sbesch: which compile errors do you get?

M.

5503 showed no compile error under Ubuntu 11.04, … and the bug is always present (5500 was in error)

These were the initial errors compiling mscore with the patch in edit.cpp (on or about r5460) with gcc4.4.3 on Ubuntu Lucid:

...libmscore/edit.cpp: In member function ‘MeasureBase* Score::insertMeasure(ElementType, MeasureBase*)’:
...libmscore/edit.cpp:2032: error: expected ‘<’ before ‘(’ token
...libmscore/edit.cpp:2032: error: expected type-specifier before ‘(’ token
...libmscore/edit.cpp:2032: error: expected ‘>’ before ‘(’ token
Line 2032 is: f = (static_cast(measure))->timesig();
...libmscore/edit.cpp:2037: error: expected ‘<’ before ‘(’ token
...libmscore/edit.cpp:2037: error: expected type-specifier before ‘(’ token
...libmscore/edit.cpp:2037: error: expected ‘>’ before ‘(’ token
Line 2037 is: f = (static_cast(prevMes)) ->timesig();

I managed to tweak the code to get rid of these syntax errors, only to get another error complaining that Class MeasureBase has no member named "timesig". At this point I decided to wait until the core dev's worked out the issue.

You pasted the code from the quotation in my post above, didn't you?

This does not work: the patch has to be properly applied (with a patching utility) from the .patch file attached to the post, as the web site text editor alters the text contents to comply with HTML (in particular, it alters the angular brackets of the static_cast clause).

As far as I can tell, if properly applied, the patch does not raise any compilation error, at least in my setup.

M.

Miwarre--I did in fact simply paste the code from your post. I will try again with the patch utility and see what happens......

The code now compiles without errors and I can insert/append measures with the correct time signature on Ubuntu Lucid. I will test this on Linux Mint v12 tomorrow,

SRB

There is some news about this bug. Before testing on Mint12, I ran svn update to r5515. When trying to patch edit.cpp, it became clear that the code in the vicinity of Line 2027 had been changed. First, the "ToDo" flag was gone, as was the code setting the default time signature to 4/4 , that is, Fraction f(4,4); was gone, having been replaced with:
Fraction f = score->sigmap()->timesig(tick).timesig();
In addition to many other changes. It seems as if the time-signature bug was the result of ongoing development in the feature set surrounding measure inserts and measure editing, which is now more complete.

I've tested measure inserts on r5515 and r5516 (today) and the bug appears to have been fixed. If you are still using an older svn revision, then Miwarre's patch does indeed work. It will not work on the newer revisions. I don't know at what revision the changes were made, but they are certainly present as of r5515. There are still some problems though, which I haven't yet had time to track down. Specifically, if you insert some measures, then drop a different time signature on one of the inserted measures (eg, extant signature is 3/4 and you drop 3/8 on an inserted measure), the program segfaults. Apparently, this only happens with inserted measures when there are already notes inserted in the measures following the insert. It does not happen with appended measures either. You can easily demonstrate this with the score that I posted above. Just insert a few measures somewhere in the middle of the score, attempt to change the time signature on one of the inserted measures, and.... "poof".

IMPORTANT UPDATE TO MESSAGE 16. The crash upon changing the time signature is NOT a segault! In fact, it is caused when the program hits an abort() call (line 494 in segment.cpp) in the function:

void Segment::add(Element *) (line 393 in segment.cpp)

If mscore comes to a non-empty measure in the process of rewriting the measures following the insert., it hits the abort when adjusting rest durations. This is clearly why the problem does not occur with appended measures. In terms of code robustness, it would be better to simply stop the rewrite at this point and leave the remaining measures untouched, but that's not what happens. Perhaps the default should be to change the time signature only in empty measures unless a new time signature is explicitly dropped on a non-empty measure. And even then, only that measure should be changed.

At any rate, there is a simple work around for those cases where a few measures of a different time signature must be inserted, for purposes of this example, let's say you want to add 2 measures of 3/8 time on a background of 3/4:

1) Insert the needed measures - These will be 3/4 measures.
2) Put a 3/4 time signature on the FIRST measure AFTER the insert.
3) Put a 3/8 time signature on the FIRST Inserted measure.

mscore will change the inserted 3/4 measures to 3/8 and split them as well, keeping the total number of beats constant. The process will stop when it hits the explicit 3/4 time signature. Thus, if you inserted 2 measures, you will now have 4. You can safely delete the extras or just start with fewer to begin with. I have not tested this with odd combinations, like 3/4 to 5/4, which may also cause problems. In such a case, I would add 5 measures that will split into 3 and leave no odd sized measures that might confuse the program.

Good work, sbesch!

Do you think this issue can be marked as solved? Maybe to open a new one, more specific?

Thanks,

M.

I agree that the original issue is essentially solved. In all probability, we should start a new issue regarding the unexpected behavior of a time signature change causing the program to abort when a non-empty measure follows the change. It isn't clear however if this always happens or if it only happens under certain conditions, such as when the measure has multiple voices or complex rest/note patterns. In any case, I still believe that the correct behavior would be to act as if an explicit time signature exists and stop changing the time signature of any non-empty measures. In fact the program should really place an explicit time signature on the first non-empty measure which exactly matches the extant time signature. The only exception would be when a new time signature is explicitly dropped on a non-empty measure. Then, and only then, should the single measure that is selected be changed as needed. Also, if the change can't be made, give a notice that the change is impossible and terminate the command, not the program. If you agree, then one of us can open a new issue. Maybe something like: "MuseScore aborts when changing time signature on inserted measures."

initial or not....
I imported a XML issued from finale

That’s a 6/4 time signature....however measure properties show 4/4 original and 3/2 actual

6/4 time signature is accepted, but this doesn’t change the properties

Ubuntu 11.04 mscore 5524

File attachment hangs....

There's no attachment.

I try again to attach

Robert---

For all the world, this looks like a completely different issue to me. Here's why:

1) The properties on the first measure (nominal 6/4, actual 3/2) and subsequent measures (nominal 4/4, actual 4/2) are not the same.
2) Actually dropping a time signature on one of these later measures has no effect on the reported properties.
3) I can change the actual to 6/4 on the first measure and the change is accepted. On subsequent measures it is not.
4) If I insert a new measure in your score, its nominal and actual time signature is in fact 6/4. Same thing if I append a new measure at the end.
5)In case 4 above, I must fix the time signature (per item 3) in the first measure before inserting/appending or the inserted/appended measures are also wrong.
6) Cutting measures with the strange properties, and then pasting them back into the newly inserted measures fixes the problem. Properties now show as 6/4 nominal, 6/4 actual. The now empty measures still have mangled properties. You need to delete them since they cannot be fixed by editing.

These things strongly suggest at least 2 bugs: One in the code that imports the Finale XML, and another in the code that references the internal measure database when getting data for the properties function. I suggest that you file a bug report on this issue. Include both the XML file and the mscz file.

Nevertheless, even though each measure still takes 6 quarter notes per 3/2 measure, I still suspect that the "properties" bug may affect other things, such as default note barring, etc. However, these issue can be worked around with some extra editing till the developers fix the import and properties bugs.

I wrote a bug report, and made a fresh import to join files… and the import was perfect ! with 5524, always ubuntu 11.04

Automatically closed -- issue fixed for 2 weeks with no activity.

Automatically closed -- issue fixed for 2 weeks with no activity.

Automatically closed -- issue fixed for 2 weeks with no activity.

Automatically closed -- issue fixed for 2 weeks with no activity.

Automatically closed -- issue fixed for 2 weeks with no activity.

Automatically closed -- issue fixed for 2 weeks with no activity.

Automatically closed -- issue fixed for 2 weeks with no activity.