tempo change via play panel causes delay or jump at repeat

This is due to the bad percentage (74%).

The playback window, as its name implies, is intended primarily to check various playback parameters. It allows among others to vary the tempo.

But this is not the right way to set up the tempo. The error is common, as it is true that this is very (too) intuitive!

This must be done either by Alt + T or by the Tempo palette. This is then modified by editing the text, or by the Inspector.
I hope to have forgotten nothing!

For your file, so, start by doing this (Palette -> Edit 80 for 89) and you will see that the issue (the per cent is now at 100%) will disappear.

Well, while it is true that a real tempo change should be inserted only via a tempo text, the relative tempo change in the play panel can be useful for proofreading or rehearsal. And this delay should not happen.
I find it difficult to pin down what is actually happening.
An interesting thing I found is that if you delete one or some measures and then undo the operation, then this delay does not appear (but it is back after closing and re-opening the score).

EDIT: Just to reassure robert.holmen.7: I can reproduce the bug as well (I forgot to mention it). I tried to investigate it, but at the moment I can't understand what is causing it (therefore my comment "I find it difficult to pin down what is actually happening").

if you increase the playback speed in play panel, it'll have a delay at the end repeat bar, if you decrease the speed, it'll not jump to the begin repeat bar, but to some place later inside that repeat. Seems it calculates the real time (based on 100%) and uses that for when/where to jump

Using v1.3, with a repeated section, using the play panel (wrongly, I read above, I should be using the tempo panel), I decrease the tempo from 120 bpm to 85 bpm, in steps of roughly 10 bpm. When I go below 85, the problem shows up as described above by Robert -- the play has a delay in it, and the play cursor does not go all the way back to the beginning of the repeated section. v1.3 downloaded tonight, Win7/64.

I confirm that when I added tempo text per the documentation, and then accessed the tempo panel with the shortcut Ctl-Alt-T that I saw in the main menu slide out, I could successfully change the tempo below 85 (I used 70), and the repeated measure problem described here did not show up. I am grateful to cadiz1 for explaining the proper way to set tempo.

The local handbook clearly says the tempo can be changed by using the play panel, or by tempo text. If the play panel cannot be used to set tempo correctly (as it obviously cannot), the documentation should be corrected.

Also, the documentation does not say anywhere that adding tempo text is _required_ to properly control tempo. Hopefully if the play panel bugs are fixed in the future, the play panel can become the main method for setting playback tempo, and the tempo text can become simply inactive, informative text for readers. I think putting the tempo on the toolbar would be a good choice for user interface.

tempo text is telling the musician what tempo to play, this is saved into the score, if not set MuseScore defaults to 120BPM.
The speed set in play panel is to override the tempo text(s) for playback with MuseScore, for e.g. rehearsal, and is not saved into the score.
So both serve their purpose. Only the playback seems to have a bug, and as you seem to have seen not only in 2.0, but also in 1.x. Interesting that nobody noticed that up to now.

The manual for 2.0 will hopefully make this clearer, see the current version in http://musescore.org/en/node/36066

Thank you for your comment and a link to the new manual page. I'm still trying to find out how to navigate this whole project and issue tracker list, so I appreciate the link. I couldn't even find the new 2.0 doc when I looked around for it last night, so I want to thank you for taking the time to send the link.

I read the new doc page, and I would agree that it does a better job at explaining the three tempo influences (default=120, tempotext = saved in the score, play panel = temp override). Even so, I still think the doc falls short of being clear (I say this as a user, and as one who has written lots of software doc in my life.)

For example, some of the details are buried way down in the text, below the play panel info.

And -- I think this is critical -- nowhere does the doc clearly say that tempo text is _required_ to really control the tempo. It seems to me that tempo text is so important that it should be _required_ by default, and should be automatically inserted into every new score. Let people make it invisible if it offends them, but it should be a required object in the score meta info.

I would also add software to display the ("stored in the score") tempo value on the toolbar in a spin box (or equivalent), to make it front and center for users to see and to change, to avoid the obscurity and problems with the existing play panel. In my experience, when some software feature has all these problems and is hard to document, the underlying design is usually at fault, and I think that's what is going on here. I'll post a cleaner design in the next message.

Always keep in mind when thinking about playback, the primary purpose of MuseScore is producing a printed (or online) score for real human musicians to read. So it definitiely makes sense for the main way of indicating tempo be something visible on the score - tempo text. Using the play panel to create some sort of invisble, meaningful-only-to-the-computer tempo indication makes about as much sense as creating invisible, meaningful-only-the-comptuer notes. Everyone accepts that the correct way to create notes is to place actual visible notes on the page. It is no different for tempo or dynamics.

The handbook for 2.0 is currently very much "Work In Progress", feel free to join in and help improving it!

Currently MS controls tempo using a default value (120 bpm), an optional piece of tempo text (eg. "Allegretto") that has a hidden tempo property that can be wildly different than the text itself, and a play panel that can temporarily change the active tempo value by multiplying the underlying (default or tempo text) value by a percentage shown on the play panel.

Documentation of this awkward design structure is also confusing (how could it be otherwise, I suppose), although doc is improved in v2.0.

--

This design model is not optimal for several reasons, as follows:

There is a default tempo value (120 bpm) that is completely out of the control of the user. The 120 value can be seen in the play panel, but the user cannot change it.

Tempo can be temporarily controlled by the play panel. The play panel is the obvious, front and center user interface to tempo values (the only tempo control the user can see off the toolbar and main menu), and yet nothing users do there is saved to the score.

The two numbers shown beside the play panel sliders (120 bpm = the underlying default) and "percentage" are not labelled effectively.

Tempo can be controlled (kind of) by tempo text in the score, and is the preferred method for controlling tempo. But the tempo text is completely optional for users. Once users go through a fair bit of learning pain, they eventually come to understand that actual tempo = [underlying tempo] * [percentage on the play panel], where underlying tempo = (default tempo, or the tempo text property value, if tempo text is present). Not intuitive.

The tempo text property value (the tempo number actually used in tempo calculations) can be wildly different than the tempo text word that shows on the score, again making it possible to confuse users. For example, I set the tempo text property to 72 bpm, even though the tempo text said "Allegretto" (more like 120 bpm).

As an aside, there are no defined "standards" for associating tempo text words or phrases such as "Allegretto moderato" with tempos. The actual bpm values are hugely dependent on the time signature (eg 2/4) and the size of the notes in the score. See the online literature for lengthy discussions on this topic.

--

A better design approach (and much easier to document) would be to do the following:

Make the optional tempo text (Allegretto, etc) inactive, and informative / decorative only. Users can make it visible on the score or not, as they please. Dissociate the tempo text completely from the underlying score tempo property.

Define a score property named Tempo (if there isn't one already), to hold the score tempo value to store with the score. This property is always present in the score xml. It can have the current default value of 120 bpm.

Add a score tempo control to both the main menu (pops up a tempo dialog) and to the toolbar (a tempo spin box or combo box). Label the controls "Score BPM" or "BPM". The visible tempo combo box values would be bpm numbers (maybe increments of 10?). When the user changes the score tempo number in the combo box, the value is stored in the score.

Define a playback tempo property to hold temporary tempo modification information. ("Playback" is a better name than "Rehearsal" tempo, because everyone understands playback. Playback is a function. Rehearsal is a purpose. People playback for many different purposes, so playback is a more general term.)

Add a playback tempo percentage control to the toolbar (eg. label it "Playback BPM%" or "BPM%" in the tooltip). Use a combo box with 10% increments for functional and doc simplicity (but other controls are also possible, if desired). Users can change this BPM% percentage without affecting the tempo stored in the score.

Add a toolbar button to pop up the playback dialog (in v1.3 you need a keystroke).

On the playback dialog, explicitly show how actual playback tempo is calculated, by showing one of the following example lines: (Text fields are in ASCII text, editable fields are in []):

Actual playback BPM = Score BPM x [BPM%]
Actual playback BPM = Score BPM [BPM] x Playback BPM% [BPM%]

The [BPM] and [BPM%] fields could be combo boxes that are synchronized to the same underlying values as are the toolbar combo boxes. I am not recommending the policy of allowing users to change both BPM and BPM% on the playback dialog here, I am merely showing a possible mechanism for doing so.

(I do admit that the policy makes perfect sense to me, to allow users to see and change both values in one place. Users would easily and intuitively understand the meaning and difference between the two values, and how they are used, if they saw them in a formula in one place in this dialog.)

--

If this design was implemented, users would have a much cleaner interface to tempo, and tempo controls would be more functional and easier to document. The design consists of:

- a score tempo property (default 120, else = value in toolbar BPM control)
- a playback tempo percentage (default 100%, else = value in toolbar BPM% control)
- a score tempo dialog available by menu or hot key
- a playback dialog available by menu or hot key

Actual playback tempo = score BPM * playback BPM%, always.
Users would see the formula in the playback panel, always.
Users could change score BPM conveniently on the toolbar or playback panel.
Users could change playback BPM% conveniently on the toolbar or playback panel.
Documentation of this would be easy; use this posting as a starting point.

--

This is a long design post, and maybe should be somewhere else (in the feature issue tracker?), but I don't know how to do any of that. So here is the best that I can do at this time.

I had an email loop with Marc, and he suggested that further traffic be placed in this forum.

Of course I understand that (1) the main purpose of MS is to produce useful notation for real musicians, (2) that composers can indicate suggested tempo using tempo text on the printed score, and that (3) everyone agrees that notes and dynamics should be visible on the page. None of these accepted principles are my concern.

My concern is that (1) visible tempo text (on the visible "printed" score) is (2) tied implicitly to (3) playback (someone called it "rehearsal" playback) within a computing / composing / rehearsing environment, and that (4) current v1.3 MS software controls (and doc) describing tempo controls are awkward and confusing.

I tried to make the point that the visible score representation (eg. tempo text = Allegro) should have _nothing_ to do with computing playback in a "rehearsal" (call it what you will) environment. Indeed, this is partially true already (no tempo text is required, and you can already affect playback tempo with the BPM% value accessible in the play panel (only it is called "Tempo" there, which is misleading, even in v2.0).

I think confusion is the result of all these partial couplings between (1) the "hidden" default value 120 of score tempo, (2) the visible tempo text name ("Allegro") if present, (3) the actual tempo text value (I lowered it to 72 with the tempo property dialog), (4) the play panel BPM% value, and (5) the actual computed playback tempo (= tempo property value * BPM%).

The fact there are 5 couplings, some overriding others, some visible, some not, and some misnamed, should be immediate evidence that the model is confusing and difficult to document.

I proposed (1) a separation of all these partially coupled relationships, (2) some changes to make the uncoupled values (score BPM, playback BPM%, actual playback BPM) easily visible in UI controls (unhide them, in other words), and (3) some changes for better naming to make documenting and understanding them easier.

If composers want to put tempo text on the score for real musicians, they still can, of course, and that is appropriate. But tempo text on the score would not have a direct effect on actual playback tempo in a computer environment.

Indeed, tempo text _already_ only has an indirect and loose relationship to actual playback tempo, because tempo text is not required, because the underlying tempo value can be wildly different than the printed word, and because the play panel percentage lies between the score tempo and the actual playback tempo.

All I was suggesting was to clean up the software model, make things more visible, more controllable, more understandable, and easier to document. No end user functionality (words on the score, score tempo value, playback percentage values, actual playback values) was removed at all.

@kkkwj: one of your posts in this isues have to do anything at all with the problem this issue is about and would most probably be better suited in a forum article, where they could be discussed.
There got to be some kind of a default playback sped and here 120BPM is as good and anything.
Tempo texts do have a meaning, some, like quarter note = 80 are immediately obvious, others like Allegro may be not, but still have a meaning. This doesn't prevent a user from setting the actual speed to something entirely unrelated (like setting Allegro to 144BPM) but hey, garbage in, garbage out, right? Whatever, these are the settings in the score. For temporary override in play back there is the play panel.
And this has a bug, causing these delays or jumps, and this is what this issue is about. Anything else doesn't really belong here.

I agree with you totally. I dutifully took my irrelevant post off-thread, but Marc requested that I move the discussion back on the thread, so I did. Who should I follow? :-)

My first point on this thread was that the bug happened to me in a fresh install of v1.3 with a dead simple score and no tempo text action whatsoever, but only when I reduced bpm on the play panel below 85 (the score value was still 120, showing in the play panel). That was relevant info, I thought.

Previous discussion on the thread got into the v2.0 doc, and an explanation (as best it could be) of the whole underlying tempo model. That doc helped me to solve my problem with a workaround (which was to define some visible tempo text, and then completely bypass it by setting the desired tempo value underneath the hood), AND that workaround let me reduce tempo without triggering the bug, which I also thought was relevant info (a workaround for the bug).

After learning "all" (do I dare claim something like that?) that there was to know about the software pieces and their partial, overlapping, hidden, undocumented interactions, I thought I would contribute a cleaner design. I had no other place to post it, being a newbie, and no knowledge of a better place. So, thinking that this thread already had info on the v2.0 doc and the other pieces, I posted it here. I did the best that I could.

I want no part of a religious war forum discussion on tempo text. I am not that naïve. So having learned how work the intricacies of the current MS temp design/implementation model, and having already made what I think were my best contributions, I will gently fade away and leave the design and UI issues to those who manage such things.

Well, it was relevant in the sense that it seems to be an old bug, rather than a regression in 2.0
When Marc asked you to take this discussion (back)to the forum, I'm pretty sure he meant forum, and not issue tracker :-) , so we're pretty much in agreement here...

I would like to add one more thing (that demonstrates some of my limited understanding of musical scores and a program as complex as MS). I was just watching some of the musecoretips.com videos, and one was on how to set playback tempo within MS.

The narrator (Kate?) made a beautiful point in her video -- she assigned multiple tempo texts to the demo score, because tempo texts can be bound to notes. To me, this is the sole valid reason for having tempo text play an active role in MS score playback. My design (in its current form) does not allow for multiple tempo texts; so my thinking was obviously limited in its scope.

At this point I still think the doc is not what it could be, and I suggest that the text from her video should be included in some form in the handbook, to explain exactly why tempo texts are the best mechanism, and why the play panel BPM% slider would (I assume) apply to all tempo texts in the score.

I apologize if I've caused any angst or confusion by my limited thinking.

FWIW, I think I probably said to continue discussion here, but I wasn't really thinking about how relevant it was here - I was just wanting it to be public. Forum does indeed make more sense since it is not related to this issue.

Check the manual again, I think I've amended it as per your hints.

Nobody ever said that MuseScore is intended for playing music, this just isn't the primary focus of MuseScore, which is notation.
This tempo change issue is a bug and should get fixed.
BTW: currently I can't reproduce it anymore?

I don't think anyone has said that the play panel is not good for varying tempo during playback - it definitely has that effect. Think of it like using your finger to slow down a record (!) on a turntable. Sure enough, you can vary the pressure as you play the record, and even speed up playback on at least some tunrtables by forcing it to go around faster. So you can indeed tempo variation as you playback. But with both the play panel and with your finger on a record, the effect is temporary - it's not something you would expect to actual modify the tempo of the music on the record or in the score. It's only in effect for the duration of that playback session.

And indeed, if the score itself has tempo changes within it, then using the play panel to slow down playback temporarily will have that effect on the tempo changes too - this works just fine. Just as it does with your finger on a record. If the music on the record goes from 200bom to 150bmp, and you use your finger to slow the record down to half time, then it will go from 100bom to 75bpm. This works exactly as you would expect.

Anyhow, there does (or did) seem to be a bug with how this interacts with the repeats in your example. It works for other files but didn't work for yours, and no one quite understood why. That doesn't mean it's not a bug, just a bug we can't easily reproduce and hence fix. And maybe it's already fixed, as a side effect of some other fix. Or maybe some other fix masked this particular case but the bug still will affect some other case. Hard to say.

As for the purpose of MuseScore - there is nothing wrong with saying it is *primarily* about notation, but that it does indeed have some playback features that are quite useful to a large number of people. Nonetheless, there will always be cases where some small minority of people will have playback needs that are too complex, too specific for MuseScore to easily support. That doesn't mean we shouldn't be able to say it does playback, because it does, and well enough to serve msot people's needs most of the time. We do try to improve it as there is time after working on the core notatio features, and we certainly try to fix outright bugs like this one when we have a clear way of reproducing the problem.

I just tried, and I cannot reproduce either. If someone else can, please give step by step instructions.

I can still reproduce.
Steps:
1- Open attached file;
2- Open Play Panel;
3- Set percentage to 200% via the Tempo slide (or click on the "100%" string, write "200%" and press Enter so that the slide is updated);
4- Play: there is a gap during playback after the first repeat.

If the Tempo slide is set to 50% than the second repetition starts in the middle of the measure.

As Jojo-Schmitz correctly points out in #6, it seems that the "jump size" (or repeat total size) is not updated when the Tempo slide is changed and retains the settings for the 100% Tempo. Therefore it lags when the Tempo is increased (the repeat plays faster, and the total size of the repeat at 100% is longer than in the 200% case) and starts inside the repeat (and not at its beginning) when the Tempo is decreased (the total size of the repeat at 100% is shorter than in the 50% case).

Windows 8.1, commit ae9f8de

Interesting; I can reproduce with that sample score but not the original one at in the first post of this issue. Any insight into why it is only an issue sometimes?

see ABL's PR #1454

I can reproduce also with the original score by following the steps in #25 (with the score from #0) just after starting MuseScore; maybe a Windows-only problem?
Windows 8.1, commit bbe146b

I think I found a possible solution: update the repeat lists when the relative tempo is changed.
Proposed PR:
https://github.com/musescore/MuseScore/pull/1454

Unfortunately the PR is not good. We can't recompute the repeat list while playing.
See https://github.com/musescore/MuseScore/pull/1454#issuecomment-64804306 for a possible solution.

What about recomputing the utick and timeOffset values only when they are accessed?
(By the way, where is the point when they are accessed by the RT thread?)
Would this create problem? (For example if the play event list has already been populated? I know little about the structure of the playback part of MuseScore)

As an extreme solution, we could disable tempo change if the score is playing, allowing it only when playback is stopped/paused.

Here https://github.com/musescore/MuseScore/blob/master/mscore/seq.cpp#L791
Or https://github.com/musescore/MuseScore/blob/master/mscore/seq.cpp#L800
maybe in other places.

Disallowing the tempo change while playing sounds extreme since it works while playing a score without repeat right?

Well, it seems that if the relative tempo is changed when playback is on there are no problems. The repeatlist update is dealt with here: https://github.com/musescore/MuseScore/blob/master/mscore/seq.cpp#L534

So it seems that the problem appears only when relative tempo is changed outside playback.
Would an "if" statement to execute the repeatlist update only when outside playback state work?

fixed in 7a647ad3dd
A call to cs->repeatList()->update() in the realtime thread in seq processMessages() should do the trick.

Fixed in 94c902213d

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