2 decimal places for tempos

• Nov 26, 2018 - 19:03
Reported version
S4 - Minor

Currently the resolution on the inspector's tempo widget is set to 1 decimal place. I need greater precision for reasons that would take a while to explain. If you need an explanation I can provide one, but it's a very simple change that has very low impact on the user experience. I will create and submit the PR as soon as I've finished submitting this issue, as my master is fully rebased at this time.


Just out of curiosity, when would one need a precision of hundredth fraction of BPM? It seems to be an order of 0.01% of the typical tempo values, isn't it?

And you don't need to create a separate PR if you wish to change something, you can git push --force your changes to the old PR's branch to get the old PR updated. It would be more convenient to discuss the changes that way I believe, provided they concern the same topic.

Yes, I'm sorry about the git problems. I rebased this branch just now and there won't be any new PRs for this issue.
As for why .01bpm? I am synchronizing exported SVG scores in JavaScript. I have a couple of topics where I discuss this, maybe I should have linked to them in the original issue:
and here:

This specific use case is the opening non-musical measure that I use to sync with videos. Videos always have an introduction of some sort, titles being the most common thing. To get millisecond precision, which is the base JavaScript timing unit for animations, I need two decimal places in the beats per minute. 1 decimal gets you close, but not close enough.
It's a workaround really, which is why I consider the justification to be less than 100% important. I really need to design and add a feature for this, but now is not the time for me, especially since I have a functioning workaround.

To be completely explicit, here is a basic example:
At 60.00bpm 1 beat = 1 second
At 60.01bpm 1 beat = 1.00167 seconds
Even two decimal places doesn't get you to millisecond precision, but it's precise enough for JavaScript animations because it's more precise than any screen refresh rate on the planet, the highest of which (commercially) is 240hz, something like that. 60hz refresh rate = 60fps = 0.0167 seconds per frame.

Maybe now you can see why I hesitated to go into detail. Once you get me started I feel I need to finish :) It's a lot of information to justify an almost insignificant change to enable a workaround.

Well, as far as I understand:
60.01 bpm equals to (60 secs / 60.01 beats) = 0,9998333611064823 secs/beat which is far more precise than millisecond.
Your calculation is probably valid for 59.90 BPM:
60 secs / 59.9 beats = 1,001669449081803 secs/beat which is indeed slightly larger than a millisecond but an order of magnitude less than that 60hz frame. Or am I mistaking somewhere?

Still the application is really interesting, I definitely didn't think about synchronizing MuseScore-rendered soundtrack with video animations.

Actually it's synchronizing the musescore-based animations with video and audio. Audio requires far greater precision in time than video. Less data per frame, but a lot more frames. Milliseconds is a sort of in-between unit that works well for sync. As soon as I can get through this next round of merging my code with the latest master and fixing a few bugs, it will we publicly released, and I will announce it in the appropriate forum on MuseScore.

Hmm. I rushed through doing that math again just now. I probably have it somewhere far back in my spreadsheet full of notes and calcs. You're right about the decimal place! I input it wrong. Let me verify your numbers... yes. I'm still more comfortable going to two decimal places. There are slower tempos than 60bpm, and I don't want to have to worry about the precision on the front end being affected by anything on the back end. Getting this stuff to run cleanly in a browser is dicey enough. I would really like to have a duration based control here, in milliseconds or even frames at preset frame rates. Tempo to time calculations are a pain, but I have some setup already so I'm sticking with that version of the workaround.

In reply to by sideways

I got my math together and if you get down to 24bpm you start to see an effect of >1 millisecond.
24bpm = 2.5 seconds per beat
23.99bpm = 2.50104 seconds per

So it is a borderline thing. I don't know too many scores that slow, and the real minimum precision is probably around 4ms. But I don't like cutting things that close.

I myself find that 1 decimal place is enough for most accelerandos and ritardandos(which is what I would use decimal places in tempos for).

I'm synchronizing to audio, video, and web animation streams. I need the greater precision, or at least I'd much prefer it. Does the extra precision bother you? The lack of precision bothers me. It's just 2 decimal places. I didn't think it would bother anyone.

Fix version