Tempo Attributes Appear Corrupted - Tempo Can't be Changed
OS: Windows 7 Home Premium; Product ID: 00359-OEM-8992687-00010.
HW: AMD-A4-3300M APU with Radeon HD Graphics 1.90 GHz.
Memory: 6.00 GB
System Type: 64 bit
Model: HP Pavilion G7
MuseScore Version: 2.0.3; Revision: 3c7a69d.
Test Filename:
Les_Cloches_de Neige_42i_Debug_20160416_01a.mscz
Description of Problem:
Tempo can not be changed using the quarter note drop-and-drag feature from the Tempo Palette – attempting to do so results in no change.
Steps to Reproduce:
(Use submitted test file: Les_Cloches_de Neige_42i_Debug_20160416_01a.mscz)
1. Open the test file Les_Cloches_de Neige_42i_Debug_20160416_01a.mscz for editing in MuseScore.
2. Click on the play button to play the score, and allow 3 measures to play. Result: The score will start playing at a tempo of 58 , according to the tempo that is assigned to the first note, shown directly above the note and the stave. However, when playback gets to the 3rd measure, it will begin playing at a much faster tempo.
3. Click the play button, again, to stop playback. Result: Playback stops.
4. From the menu, select View\Palettes. Result: The palette list appears on the left hand side of the screen.
5. Open the Tempo palette by clicking on the Tempo palette. Result: The Tempo palette opens with a drop-down list.
6. Click and drag the = 80 (top right of possible selections) to the score, dropping on the 16th note in the third measure. A tempo symbol will appear above the note and stave, showing a default value of 80 assigned to it.
7. Double-click on the text, “80”. Result: The text insert cursor appears somewhere with the text string, according to where the mouse pointer was positioned.
8. Use the keyboard to change “80” to a tempo value that will result in a noticeably slower tempo during playback (i.e. 38). Hit keyboard key, , or click outside of the tempo value so that the new tempo value is set. Result: The new tempo value string remains as the tempo value within the tempo symbol.
9. Click the Rewind button, |<< , next to the play button, so that the start position of playback is reset to the beginning of the score. Result: There is no visible result, but the playback start position is reset to the beginning.
10. Click the Play button. Result: The score will begin playing at the first tempo (58), but when it gets to the first note in the 3rd measure, playback will jump to the same tempo that it did before the change was made in Step 8.
Comments:
1. Changing the “Tempo Marking” parameters in the Inspector window has no affect on playback tempo.
2. This problem first appeared after Tubular Bells was added to the bottom of the instrument list, and Crotales was removed from the bottom of the instrument list, not necessarily in that order. Typical arrangement changes were also made to the score.
Score Order BEFORE corruption:
Bflat Cornet
Bflat Cornet
Bflat Cornet
Tenor Trombone
Bass Trombone
Tuba
Piano
Violin 1
Violin 2
Violin 3
Viola 1
Viola 2
Violoncello
Contrabass
Bflat Clarinet
Bflat Clarinet
Oboe
English Horn
Flute
Piccolo
Cymbal
Wood Blocks
Crotales
Comments
Your score has an invisible tempo marking in measure 3, that is why the tempo changes there. Do have any idea how that might have happened? In earlier versions of MuseScore, there were bugs where if you tried deleting all characters from a tempo marking as opposed to deleting the tempo marking itself, you could be left in this state. But in 2.0.3, this should be fixed - deleting all characters from a tempo marking deletes the marking entirely, so you aren't left with an inivisible tempo marking. I'm guessing this score was originally created in an earlier version, in which case we can close this issue as already fixed.
If on the other hand you can provide steps to reproduce this issue in a score created from scratch in 2.0.3, please provide the steps to do so.
Meanwhile, you can fix your score by right clicking the tempo marking in bar 1, then Select / All Similar Elements, then Delete.
If I could have provided the steps to reproduce the problem, don't you think I would have already done so? The problem did not show up until 2 days after Revision 2.0.3 was installed on April 12. Four new measures were added to the beginning of the score, but I have several versions that worked fine, after that change, and before this problem appeared.
Is there a way to make the "invisible" tempo marking visible, so that it can be deleted? Why is it invisible?
I have a fair amount of tempo changes through out the score, and it wouldn't make sense do delete all of them at once, if avoidable.
You can save as mscx and use a plain text editor to find and delete that invisible tempo marking.
Measure 3, where this bug is found, did not exist until a few days ago, when four new measures were inserted, and after Rev 2.0.3 was installed. So, I would tend to think that the problem was not pre-existing within the score.
Could be, but it could also be that the marking was there in the measure you inserted before, and it was moved to the new measure. It's also possible that while the *measure* didn't exist, it's *content* might have, if you copied and pasted it from elsewhere. If you only added the measure a few days ago, hopefully you can remember something about how the content got there - did you enter it from scratch or copy and paste it from elsewhere? Did you at one point have a tempo marking there and try to delete it?
A safe way to delete just that tempo change would be to first select the measure, then right click a tempo marking (anywhere) and Select / All Similar Elements in Range Selection. This will cause only the invisible tempo marking in that measure to be selected, and then Delete will be safe.
As for making invisible tempo markings invisible, I don't know a way to do that directly - it isn't supposed to be possible to createm in the first place. But I would note you can Shift+drag select the area above the measure and catch it - you'll see the Inspector reflect the fact that a tempo marking is selected. In general, though, this won't be as reliable a method as Select / All Similar Elements in Range Selection, because you don't necessarily know where the marking actually is, and there might be other markings in the way.
There was an existing visible tempo marking at the 2nd measure, before I inserted 8 new measures at the beginning of the score. I then added notes to the 8 measures, then added a tempo marking to the new first measure. After that, I deleted the 2nd, 4th, 6th, and 8th new measures.
The version with the filled 8 measures, without the new first measure tempo marking is Ok. However, the next version, with the deleted four measures and inserted first measure tempo marking, also contains the invisible tempo marking. Note that before editing to create the test file, the original visible tempo marking (6th measure) was present, but had no affect because it was in the 5th measure, before the invisible tempo marking in the 6th measure. Perhaps removing it to create the test file affected your analysis. Here is a test file that more closely resembles the original version of the score where the defect first showed up: Les_Cloches_de_Neige - Test_InvisibleTempoBug_42i.mscz
Of course, changing the 'visible' second tempo marking did not have a noticeable affect on the tempo.
I've gone back and repeated all these steps, but with no success in reproducing the bug. This is an apparent 'invisibility' bug. I successfully edited the uncompressed file so that the invisible tempo marking is no longer present, and really do appreciate your suggestion that helped me fix it.
You're welcome! FWIW, the original bug in older versiosn that was known to lead to this state had to do with text elements that had mixed regular and bold fonts. Some specific series of steps editing the text where you ended up with no characters left, but there were still empty XML tags to indicate the switch to bold, and that prevented the text from being detected as completely empty (which would normally trigger the deletion of the text). I don't recall the exact sequence of steps that would lead to this and I can't reproduce either, but I wouldn't be surprised if some corner case remained in this area.