Set rit. and accel. tempo change in BPM as well as percent

[ChriiMoral]

Your idea

Currently, when opening the Playback options of accel., or rit., the tempo change amount is set to a percentage... which is unclear. I don't know what percentage would I need, to increase from 64bpm, to 70bpm (for example). As the title suggests, it would be clearer for users if the tempo change amount was instead a targeted tempo (in bpm).

Problem to be solved

Eliminate the need to calculate or guess the corresponding percentage to get the desired tempo change. Allow users to chose whether they prefer Percentage amount or Targeted Tempo.

Prior art

N/A

Additional context

Concept

[DaddyLudwig]

I would certainly appreciate the option of targeted BPM alongside the preexisting percentage option. Cause I don't think "Okay, I need to ritardando to half speed so 50%." or whatever, no, I think more like "Okay, I'm at 120, I want to ritardando to 60 here."

[ChriiMoral]

That was exactly my thought process.

I wouldn't remove the percentage option in case anyone prefers it, but Targeted BPM, in my opinion, would be more useful for most people.

[Beniegenie]

I have to say I agree. They could make it so you can set the percentage with the bpm and vice versa.

[mmeyn]

Some thoughts on this:

1. MuseScore should respect whether the ritardando* amount was set as a factor (percentage) or target tempo (BPM) for the future, i. e. when changing the BPM before the ritardando
   • for explicitely set factor the target BPM should change and
   • for explicitely set target BPM the factor should change.
     This means that only one of the options should be explicitely set (and stored to the file) and the other should be calculated in a getter method.
2. There might be rounding issues. Currently, the percentage does not allow decimal places.
3. The change in BPM should be a target BPM, not a difference (i. e. a ritardando from 120 BPM to 90 BPM should not have a difference of 30 BPM but the absolute target of 90 BPM).
4. When you add a ritardando which ends directly at a tempo mark, the BPM of that mark could (and IMO should) be used as target tempo (instead of using an explicit factor).

*I choose this as an example for gradual tempo changes so that I don’t confuse myself with too many occurences of the word “change” …

[iainhallam]

@mmeyn With you on the first three, but for "When you add a ritardando which ends directly at a tempo mark, the BPM of that mark could (and IMO should) be used as target tempo (instead of using an explicit factor).", I often need to do a rit. just before a new tempo (which is faster than the rit.), and this would mean overriding the behaviour somehow for each one.

[DaddyLudwig]

@mmeyn Honestly, with how much I round tempos to begin with, the second point wouldn’t be an issue for me. Like, I round to the nearest multiple of 5 anyway since that’s the difference my ears detect as "real tempo change, not just rubato", so…

[ChriiMoral]

@mmeyn Yes, this would be a great implementation! However, I'm with @iainhallam on the last point.

Sometimes, we might want a rit… to be followed by a more dramatic tempo change, and so, that behaviour, of using the tempo mark as the target tempo might be a problem.

This could also be an option on the Properties pane, in case any one would prefer to have their new tempo mark be the targeted tempo (kind of like how tempo markings currently have the option to follow their text, or to have a distinct tempo specified on the Properties).

I appreciate y'all's involvement in this!

[ChriiMoral]

@mmeyn Honestly, with how much I round tempos to begin with, the second point wouldn’t be an issue for me. Like, I round to the nearest multiple of 5 anyway since that’s the difference my ears detect as "real tempo change, not just rubato", so…

Yeah, I do understand. However, it would still be useful to have that option in case one is scoring for a preexisting track that might have an odd tempo (with decimals). I've had to do this kind of work before and I'm glad decimals are allowed in general.

But thanks for sharing your point of view!

[wizofaus]

Happy to implement this if we can get basic agreement on what the UI should look like. Have wanted this a few times recently.