'Tempo follows text' stopped working
Hiya
The last few nightly builds seem to have an issue with tempo. There is html appearing after the imported tempo marking in the R.37db5d7 nightly build. (Guessing it's missing an end tag? It goes away when you replace it with a new one.) However, the last few nightly builds don't seem to observe tempo during playback.
Ex. Current piece starts at 90bpm, moves to 110bpm 13 measures in, 120bpm 57 measures in, and 130bpm (maybe 140bpm) at measure 78. I also attempted to create a rit. on the last few measure, but without success. I've simply been adjusting it in the play panel, so it's not a huge issue. I've included the score and a WAV (Link: https://dl.dropboxusercontent.com/u/1071779/Evening_Adventures2.wav ) so you can see what I mean.Thanks!
Cheers!
Attachment | Size |
---|---|
Evening_Adventures2.mscz | 12.31 KB |
Comments
Possibly related to 89dce19
Hmm, I don't see the html in tempo texts, using 8b1af15
Except, maybe, for tempo texts using dotted half notes, looking into this right now...
The html issues should be fixed in 2d6d0b8
Not the 'tempo follows text' issue though.
Not sure if it's related, but I noticed something similar with HTML appearing in composer text.
This was in a score created in 2.0 (for testing purposes) and opened in a later build.
Using MuseScore 2.0 Nightly Build (8b1af15) - Mac 10.7.5.
that might be related to 1b1f704 and might be an unavoidable issue, no backward compatibility to older nightlies.
I think the "follow text" property for tempo text got broken during the changes in text-handling of the last days.
If you highlight your tempo changes (one by one), uncheck in the inspector "follow text" and set the desired tempo, the score should play as expected.
Ooo you're right! It did. Well done. Thank you.
Tempo follow text works for me here. Using Windows e510aab95f
Can someone give exact steps to reproduce from scratch?
I can't reproduce from scratch, but with the file attached to this issue report.
Since compatibility is not guaranteed for scores saved with ongoing development version, I think this bug can be closed.
The only thing I see from scratch is that if you uncheck the "tempo follow text" button, set a time different from the one written and then re-enable "tempo follow text", then the tempo is the one you manually set until you double-click the text and then exit again text-edit mode. If you save before this double-click and reload the tempo is still the manually set one even if the "tempo follow text" button is checked.
Just an observation: if you open the file attached to the issues report ("Evening_Adventures2.mscz"), double click one of the tempo texts, move the cursor to the end of the text and press backspace, the last character is not deleted, but the last-but-one character is deleted instead. I couldn't reproduce this behavior from scratch.
Windows 8.1, commit 1d39023 (self-compiled debug build)
Not sure whether this is the same or a different issue:
1. in a score without any tempo text apply a tempo text from the palette to a note not in the 1st few measures, e.g. quarter = 80.
Playback should now start with 120BPM (the default) and switch to 80BPM at that tempo text.
2. in inspector switch of the 'Follow Text', change the tempo value to e.g. 40.
Playback should still start with 120BPM, and then switch to 40BPM. So far so good
3. now switch 'Follow text' back on
Expected result:
Playback should still start with 120BPM and switch to 80BPM again at that tempo text, as that text hasn't been changed.
Actual result:
Playback still starts with 120BPM (which is OK), and then switches to 40BPM (which is not OK).
On top: If 'Follow Text' is enabled, the tempo filed in Inspector should show the 'detected' tempo, even if that filed is now disabled for input.
Relates to #272381: [EPIC] Tempotext issues
Tested on OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 2c43063
Jojo-Schmitz scenario works correct.
Automatically closed -- issue fixed for 2 weeks with no activity.