Metronome ticks do not always match reference beat value

• Apr 24, 2020 - 23:07
Reported version
3.4
Type
Ergonomical (UX)
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

When using non-standard note values for the reference beat in the tempo, the ticking of the metronome--when enabled in the play panel--still reflects the standard reference beat.

When I enter a tempo marking using a eighth note as the reference beat for a common time piece, (e.g. (eighth note) = 120), and then enable the metronome in the playback panel, I would expect the metronome to be ticking at 120 bpm, rather than sixty, which is currently the case.

This currently is doubly confusing with six-eight time. Say a user creates a score using a dotted-quarter reference tempo of 60 bpm. The metronome will beat at sixty bpm, which would be expected. However, the "Tempo" label on the play panel still reads "90 BPM", since it uses the quarter note as its reference.

Now most of the time, having the standard rhythm inform the metronome is a really good thing, but in situations like these, it's probably important to provide some visual indication of the value of the reference beat in the play panel.

I think that this should likely be configurable, so a fix might be to have a drop-down, or pop-out option in the playback panel to choose the reference metronome tick. As long as there was some visual indication of where the metronome would tick, this would do the trick.


Comments

I wouldn't say this is a duplicate, since what I'm really trying to address here is that it is unclear what the metronome is using as it's reference beat until I press play. I'm also trying to trigger some discussion about why that design decision was made and if it continues to make sense.

I understand that, but the UI has little indication of that, and the BPM number under the tempo adjuster in the play panel is using a different note value as it's reference beat.

What I am saying is that this makes the UX for the metronome bad. Things aren't working quite the way they're expected for a new user.

This is a good opportunity to revisit using the time signature to determine the ticks exclusively. I'm not sure it makes that much sense. Certainly you would like the option to here ticks on certain subdivisions of beats? I imagine that it might help some composers as well as many people trying to use musescore to learn to play a composition.

In reply to by Jojo-Schmitz

I did a little test of the metronome. for a non-compound time signature, the metronome follows the time signature. If you specify N beat in a bar, you get N clicks in a bar, no matter what the tempo text says. However, for a compound time signature, you can have N/3 clicks in a bar if you have a dotted note in the tempo marking, or you can have N clicks if you have a non-dotted note. Note that for the compound time signature the dotted note or undotted note in the tempo marking must correspond to the time signature denominator. So for a 6/8 time signature a dotted crotchet gives you two ticks per bar, a quaver, gives you 6 clicks and for a 6/4 time signature a dotted minim gives you two ticks while a crotchet gives you 6 clicks. Anything shorter, for example a semiquaver in the tempo marking with a 6/8 time signature still gives you 6 clicks rather than 12.

One nice feature of the metronome in compound time signatures is that when clicking according to the short note tempo indication (quaver beat in 6/8) it emphasises the main beats.

See the attached examples.

Metronome test.mscz

I agree with the OP, the metronome should follow the tempo marking and use the beat length specified in the quantum of the tempo marking. The BPM indication should do whatever the the metronome does. I note that that BPM indicator behaviour was what I originally had in #291727: Improve tempo indication in Play Panel to reflect time signature but I changed my mind to have the BPM following the time signature. I wish I hadn't now. If the metronome can do it in limited circumstances for compound time signatures, why not have it do the same for non-compound? And while we are at it, why not have the metronome follow even shorter quantums for all time signatures.

Attachment Size
Metronome test.mscz 5.53 KB

In reply to by Jojo-Schmitz

But it is a more general issue (problem?) than just for new scores. The suggestion is that BPM should follow the "B"eat length specified in the tempo text (crotchet = x, quaver = x etc.) and the metronome should follow that. The beat length suggested as a default when using the new score wizard (the tempo text following the key signature feature that you describe) is useful but if the user overrides the default beat length in a tempo text, then Musescore should similarly override the beat length used in the BPM setting/display box and in determining the interval between metronome clicks.

The suggestion is that BPM should follow the "B"eat length specified in the tempo text
Amd that'd be just wrong. A tempo text may not even exist. A time signature though always does (at least a nominal mesure duration)
So the tempo text needs to follow the time sig. And the metronome too.

In reply to by Jojo-Schmitz

Are you thinking of something like dotted crotchet = x with a 4/4 time signature. Well, if users add stupid tempo markings they should not complain if they get stupid results, but they could be protected by only allowing beat lengths that make sense in the current time signature context. If the time signature changes to make the current beat length invalid and the user does not add a valid tempo marking then a default based on the time signature could be used.

In reply to by SteveBlower

Allowing the metronome to follow the tempo text instead of time signature is useful but must be an option (an additional check box in the play panel). I'm thinking to waltz in 3/4 at dotted minim = 66, metronome at 66 is generally preferred to metronome at 198.
But more useful than that option would be to allow to select the beat length in the play panel. Because, when for the same Waltz you exercise at 50% speed, then metronome at 99 is a lot better than 33 ...

In reply to by frfancha

So if you don't want the metronome set at 198 don't add a tempo text of crotchet = 198 but instead add one that says dotted minim = 66 and, if this suggestion is implemented, Musescore would tick once every 1/66th of a minute.

There may be some different ideas about what the new score wizard would offer as the default, dotted minim = x or crotchet = 3x but that does not affect my argument that it would be a Good Thing for metronome and BPM to follow what the user has specified in a tempo text (providing it makes sense of course) even if that is just accepting the wizard's suggestion.

In reply to by SteveBlower

Yes of course I would add the text saying dotted minim = 66. What I say is that I don't want to have to remove that text any time I want to exercise with the metronome beating the crotchet. I want to be able to easily select the crotchet beat in the play panel.

In reply to by Jojo-Schmitz

@Jojo I don't think so, and the example of 3/4 scores shows that clearly: for some of them it is the crotchet the preferred beat value, for other ones (typically fast Waltz) it is the dotted minim. The tempo text is precisely what enables MuseScore to know which one to use.

In reply to by frfancha

@ffrancha But what if you wanted quaver beats or even semiquaver beats (useful for practice purposes sometimes)? There would have to be buttons for every eventuality in the play panel. It seems reasonable to me that if you have specified one thing and then want a different thing you should replace the first thing you specified.

In reply to by SteveBlower

To bring out another point made earlier. Musescore already has some capabilities in this. In 6/8 or 9/8 etc. you can specify either a dotted crotchet beat or a quaver beat in the tempo text and Musescore honour it in the metronome by clicking at dotted crotchet or quaver intervals according to the tempo text. This suggestion is just an extension of that facility.

In reply to by SteveBlower

Steve, play panel allows you to change the play speed, right?
You don't need to edit your tempo text to change the speed, right?
Why on earth are you insisting that play panel should not allow you to change metronome beat and that that change can only be obtained by changing the tempo text is beyond my understanding

In reply to by frfancha

Not only by changing the tempo text then, but at least by changing the tempo text. But how do you deal with minim/crotchet/quaver/semiquaver and their dotted versions in the play panel? Eight buttons? Also, the play panel specifies the global tempo for the score. What happens if you go from 3/4 to 6/8 say with a crotchet beat specified in the play panel. You can have different tempo texts at different places in the score.

Status duplicate active

Changing back from duplicate to active because this has garnered a separate, useful discussion.

So we have a few issues that are related here, I think. The play panel is meant to be global, which necessarily decouples it from things like tempo texts (correct any misinterpretations, please). A good example of this is the tempo slider, which adjusts the tempo of the entire piece by a certain percentage.

Since, in pieces where the time signature changes between common and compound metre (e.g. 4/4 to 6/8 with dotted quarter beats), the metronome already adjusts beat value based on the metre change, this should be able to keep track of metres described in the tempo markings that use nonstandard reference beats.

Proposal for discussion: metronome ticks default to expectation of metre based on time signature, to be overridden by the tempo markings as we've discussed, and then the play panel has a toggle for subdividing the beat, with a drop-down for the subdivision value?

Let's discuss the use cases this might succeed at and the ones it doesn't meet. As well as potential pitfalls.

That issue is pretty stale, however, sitting at two and a half years since it's last comment. You're more familiar with Musescore Dev flow. Is it better to revive that thread and issue, or just stick to this one.