Changing Tempo only via Play Panel

• Apr 20, 2016 - 20:14
Reported version
3.0
Type
Functional
Severity
S3 - Major
Status
closed
Project

And even then there are inaccuracies in the play panel's representation of the tempo. But first, steps to reproduce:
1) open the attached file, which has a tempo of 100bpm
2) click on the tempo text, and open the inspector (F8 key)
3) open the Play Panel (F11 key)
4) this tempo text is disconnected from the text value, so change the tempo in the inspector to 20bpm.
5) look at the Play Panel - the tempo has not changed. press the Play button. It plays back at 100bpm.
6) if you change the tempo in the Play Panel, then the tempo really changes
Note that this probably affects MIDI exports, it definitely affects my VTT exports - this is the current tempo of the score as far as MuseScore is concerned.
This might mean that tempo changes in a score are being ignored, I did not test that.
I verified that in 2.2 this works properly. (sorry 2.2 is still a reference for me, since it's pre-my code)

Also note, that if you change the tempo in the Play Panel using the slider (for example so that the % input shows 50%, it does not actually give you 50%, it can vary +/- 1%. The way to get a precise number is via typing 50% into the input box. I was looking at VTT files, and the timing was off until I typed in the value. I don't know if that precision is important, but it is slightly misleading when the display says 60bpm and I'm actually playing back at 61 or 59 bpm.

Attachment Size
mm72.mscz 10.82 KB

Comments

I am also getting this a lot in the debug console:
{syntaxhighlighter SPEC}
Debug: TempoMap: empty (Z:\MuseScore\libmscore\tempo.cpp:256, qreal Ms::TempoMap::tick2time(int, int*) const)
{/syntaxhighlighter}
In case that is helpful in solving the problem.

Also, I overstated the rounding error in tempo that I described above. It still exists, but it's not a whole bpm of variance, at least not at 60bpm. It's still an issue, though. If you're going to display 50% and 60bpm, it should not be 60.1bpm, for example. The longer the score, the more out-of-sync it gets.

I hope it's OK if I up the priority on this to "major". It really is a serious bug that tempo markings are being completely ignored. Set it back to "normal" if I've overstepped my authority. Thanks.

Status (old) active needs info

I'm not quite undertanding the steps. Which play button do I need to press at step 5 to hear a problem? I tried the one within the play panel as well as the one in the main toolbar, also tried the space bar. All played back correctly (20 bpm).

It's normal that roundoff might be applied to the scaling factor. Remember, it's only a scaling factor meant for temporary overrides to the real tempo. The tempo marking in the score is the only real tempo - consider the tempo might change mid score anyhow.

OK, I just reproduced it again, so let's try some alt steps:
1) open the score
2) open the play panel (press the F11 key, or click the View menu Play Panel option)
3) note the the tempo is at the default 120bpm. If you press the plan button in the play panel, the score plays back at 120bpm.
4) now select the tempo text, open the inspector, and change the tempo to 20bpm
5) go back to the play panel and it still shows 120bpm and still plays back at 120bpm

Leave the play panel open the entire time, though I don't think that makes a difference.
The way to reproduce the debug messages is to do anything with the score's TempoMap, which appears to be empty, in spite of the tempo text.

Are you sure this is the right score for those steps? Default tempo in the one you posted originally was 100. Following the steps in your response above works correctly for me. Which build are you using (Help / About)?

For me, the tempo shows 100 in the Play Panel until I actually hit the Play button, but it changes to 20 immediately and plays back correctly.

Status (old) needs info fixed

OK, this is fixed in the latest master. It must have been fixed in the past couple of days, I've been rebasing almost every day lately.

I have 2 non-master branches going, and the primary one seems to have the old version of that line of code, so you must be right. Though I was sure I had tested this against a pure master build prior to posting it. Oh well.

btw - I am right now having a heck of a time rebasing that branch. Ugh! And I really want this fix in that branch! Obviously I could insert an exclamation point character and really see if that's what solved the problem, but I'd rather get in sync with all the latest fixes, because there are a lot of them.

I'm going to push a little harder to have my new feature request for points/pixels as a page layout option integrated. That's the source of much of my rebasing pain, and it really is a good feature.

https://musescore.org/en/node/106861

Unfortunately, it touches a lot of files and requires serious review. I'll continue that discussion in that thread. Thanks.