Please add preference for previewing clicked/selected notes at playback velocity (rather than velocity 80)

• Jul 13, 2021 - 05:55

In Musescore—regardless of a note’s assigned velocity, and without regard to other attenuating factors like dynamics and accent makes—a clicked note always plays at a preset velocity of 80 ... NOT according to the note's Offset or User velocity (with all other playback influencing factors in the score.)

This behavior prevents one from previewing a note's velocity by clicking it. And trust me, when velocities in a score are quite low, it can be rather startling hearing comparatively a poked note sound off at velocity 80.

The same "velocity 80" behavior occurs when using the left or right arrow keys to strut through a string of notes. The arrows keys would provide a great way to quickly audition notes … to see which ones might need velocity adjustments. But, best I can tell, we don't currently have that.

I would LOVE a preference option that allows clicks and arrows to audition notes at their play “volume.” I'd turn that option on and leave it on.

Is there a short list of obvious benefits in the "always plays velocity 80" current behavior?



This has come up before, and I believe that the explanation was that MuseScore can't actually calculate the velocity of a note until the play algorithm is active. There are several things which can effect the note-on velocity, which include more than just the dynamic marking. (accents, sfz markings, hairpins, etc.) As far as I know, these aren't applied to the notes until you actually press play.

In addition, editing a dynamic affects all subsequent notes. (until the next dynamic is applied) Rather than changing the velocity of all the notes from 64 to 80, for example, and then factoring in articulations to achieve an absolute value, MuseScore keeps a tally of these events and applies them at playback.

I'm sure I've got at least part of this wrong, but that is my understanding at the present.

In reply to by toffle

FWIW, it may have been true at one point that the information isn't available at that moment, but I don't think that's likely true any more - we do preprocess the score on a pretty regular basis in such a way that this would probably be readily available. At least, in 3.x source - much about playback is totally reworked for MsueScore 4, and I have no insight into that. On the other hand, since the advent of single note dynamics "velocity" is not normally the most relevant aspect of how loud a note sounds, so I'm not sure you'd get much value out of hearing a note at the same velocity unless we also reproduced the exact setting of the CC messages used to control the volume as well. I'm not sure that information is as readily available.

Mostly, though, I just don't think many people would like it if notes that happened to be marked ppp were hard to hear while editing, so the request doesn't come up very often, so it was never considered a particularly important feature to try to provide. But assuming it really is possible at all, adding another option to the preferences dialog (there is already one to set the duration of a clicked note) wouldn't be a big deal.

I support scorster's aspirations, but I think toffle is likely correct as to why this might be difficult to do.

But while the topic is open:

• I think that the poked note should sound as long as we lay on it, without the maximum enforced by the current system.

• On the other side of that coin, I think the minimum sounding time (which we experience if we just "tap" the note) is too short. I would think that this minimum toot should be long enough that for the typical patch the note's ADSR profile has a chance to reach "steady state".

• [We may already have this and I just don't know how to invoke it; if so, never mind.] It would be nice if, perhaps through the use of a modification key, we could poke a note and have the entire chord (if applicable) sound.

As an aside, I call attention to the fact that when we poke a note (or step to one while "walking and tooting"), the corresponding MIDI Note ON message is sent, but no Note OFF message. Instead, MuseScore relies on the fact that, after the period the note is to sound, the "end of play" sequence is sent, consisting of (among other ingredients) a Note OFF message for each possible MIDI note pitch (128 in all) for each staff in the score (on the MIDI channel assigned to that staff).

[I will discuss - and cuss - that in a separate thread to come shortly]

That shuts off the sounding of the poked note, all right, but I think it is "dangerous" to rely on that, and this could come to bite somebody if any change is made in the end-of-play sequence (and it certainly needs that).

Best regards,


In reply to by Doug Kerr

Hi, Marc:

> (there is already one to set the duration of a clicked note)

Oops! I didn't know that. Thanks.

Ah, that is the "maximum", not the "minimum". (I'm not sure why there needs to be a maximum.)

I see there is an option for "sound whole chord".

Ah, that works when adding notes, but not when poking them.



Marc wrote > [this] was never considered a particularly important feature to try to provide.

Musescore preprocess[es] the score on a pretty regular basis in such a way that this [information] would probably be readily available. [However] I’m not sure you'd get much value … unless we also reproduced the exact setting of the CC messages used to control the volume as well. I'm not sure that information is as readily available.

Assuming it really is possible … adding another option to the preferences dialog … wouldn't be a big deal.

I hope developers can combine the preprocessing of score velocities and CC messages, such that we'll have a Preference that allows clicked notes to sound at their playback level. (Same goes for notes played by left and right arrows.)

I've not had good luck searching the Issue Tracker for topics, so can you tell if there's already an official request on this matter? If not, I'll be glad to add one.

Much appreciated!


It would be ideal if a selected note could sound at its playback velocity but given that there are some technical difficulties with this it would be nice to have a setting to define the velocity of clicked notes in the preferences – just as we can define their duration.

On working with pp sections of a score, (around velocity 32), I need the Windows playback volume at around 40% to hear things, but then when I click on a note to edit it I get my hearing blasted with velocity 80. Ouch!

In reply to by worldwideweary

I don't see a Github post for this issue. So I'll add one later today. UPDATE: You can find my Github request here.

I agree with yonah_ag: The most jarring impact of the current situation is when you're listening for notes to edit in a ppp section. At such a low sound pressure you may choose to turn up the volume significantly on your audio interface or speakers. Then you click a note ... and Musescore blasts you because it ignores velocity and dynamic on click.

There's another advantage (use case) for previewing a note's playback volume as heard when clicking the note ... or when right/left arrowing to it. A realistic preview makes it very easy to pinpoint notes with inappropriate velocities. As it stands, we have to play the score to find the culprits and then the additional step of selecting the note for edit. This becomes a one step process if MuseScore previews the note according to velocity + dynamic.

Then in MS4, there's the matter of accessing the note's velocity field. This is more problematic in MS4 because the note velocity field is buried one needless level deeper in the Properties panel ... plus "undisclosed" itself whenever you click something other than a note. A "stay open" lock toggle would resolve that issue. But I'd rather see the velocity field moved into the Notes panel and thus we'd find it always visible when there's a note selected.

And here is a relevant Github post:

I didn't scour this thread to see if it contains this link, but it's relevant: (same as above)

Do you still have an unanswered question? Please log in first to post your question.