Playback velocity vs. clicked velocity

• Dec 7, 2020 - 01:04

As seen in the attached score, clicking a note does not preview its User or Offset play velocity.

Play velocity vs Click Velocity.mscz

Is this by design? Or is there something in my score that prevents Playback velocity = Clicked velocity?

Thanks!

scorster


Comments

This is by design. It's so if you put ppp as the dynamic you will still hear it and fff won't blow you away if your speaker is cranked up to hear ppp.

In reply to by mike320

Thanks Mike,

I was afraid that was the underlying reasoning.

Is there a preference that allows users to defeat this "feature"?

I'd rather determine a note's play volume by clicking it, and rely on my own sensibilities to protect my ears and audio equipment.

scorster

In reply to by scorster

No properties to change it. One note in isolation really doesn't tell a story by its velocity. I don't make decisions but I do understand the decision. Part of the decision is that you can't take a note in isolation and determine it's velocity. The context is required. What I mean is if you put p < fff as the dynamics, there is no way to ask MuseScore what the velocity of the 3rd note above the hairpin (<) is.

In reply to by mike320

Hi Mike,

Thanks, as always.

>> No properties to change it.

Sorry to hear there's no preference to make clicked velocity = playback velocity.

>> One note in isolation really doesn't tell a story by its velocity.

Correct. I'd assumed that the play volume would take into account "chasing" dynamic marks, accents etc. Is that what you mean?

>> if you put p < fff as the dynamics, there is no way to ask MuseScore what the velocity of the 3rd note above the hairpin (<) is.

But MuseScore manages those velocity/volume decisions on the fly during playback export. So why would that be challenging or impossible on click.

scorster

In reply to by scorster

Do you want to wait 45 minutes for the last note of Dvorak's 9th symphony to respond to a click? It could probably be calculated from a later point in the music for Dvorak's 9th but Ravel's Bolero, which from my memory is about 10+ minutes, is one big crescendo from the first note to the last. So assuming a 10 minute piece it would take about 10 minutes to calculate the velocity of a note in the last measure.

What I thought of after my previous post with the p < fff example is this question. What if there is one dotted whole note above the < in 6/4 time, at what point in the note's playback would you expect to hear when you click it? the p at the beginning? the fff at the end? or somewhere between mf and f at the half way point? Don't take me wrong, I'm not doing anything but considering the different possibilities.

In reply to by scorster

> "But MuseScore manages those velocity/volume decisions on the fly during playback export. So why would that be challenging or impossible on click."
It doesn't.

For playback (when you press rewind/play the first time) MuseScore pre-processes the whole score to figure out resulting velocity.
On single click, due to the simplicity only the note itself is regarded and not any of its surroundings; to prevent slowing down interactions when clicking a note. After all there are a bunch of reasons to click a note and hearing it is but one of them. This will slow down user interactions when they're ctrl-clicking notes into a selection for example.

Again, it's not that it is impossible on click; but it is a challenge to determine what elements should all be taken into consideration to make a good analysis, perform that analysis and still be fast enough so the user doesn't notice any of the delay caused by such analysis.

In reply to by jeetee

Thanks guys.

jeetee wrote >> MuseScore pre-processes the whole score to figure out resulting velocity.

>  Thanks. I didn't know that. I figured there was some way MuseScore chased matters like dynamics, but didn't realize it preprocessed the entire score.

jeetee wrote >> On single click, due to the simplicity only the note itself is regarded and not any of its surroundings ... it is a challenge to determine what elements should all be taken into consideration

>  I'd be perfectly happy if MuseScore simply played the note according to its velocity.

I'm not looking for utter perfection with regard to staging dynamics like ff, crescendos, accent marks, etc. But nullifying all velocity playback seems a excessively cautious approach on MuseScore's part—and it makes it harder to edit velocities, because I can't preview them on staff with a simple click, nor with right/left arrows.

When I've got a string of 120 64th notes, and one is too loud, it would be nice to click or arrow back and forth to find it. But that's of no use because MuseScore won't play the velocities. And yes, I could switch to the Piano Roll Editor, but ...

scorster

In reply to by scorster

To get what you describe, you would need a situation like what Jeetee showed in his example, the velocity of the note has been accidentally or purposely changed. In such a case you can open the inspector and get continuous feed back on each note by selecting one and pressing the right arrow until you see the note with the strange velocity set. You may need to collapse a section for velocity to be shown, but that's not a problem in my view. If you set this up with my p

In reply to by scorster

Thanks for the workaround guys. Indeed I can use eyes instead of ears—and have done so—but haven't needed to in my most used app where a clicked not plays its velocity.

The suggested workaround highlights MuseScore's current reality. It also underscores the need to realize the "volume" of notes according to their velocity when clicked and/or via right or left arrows; and when I say "realize," I mean simply, without concern for every possible volume contributing or mitigating score element. Sure that's not perfect, but to me it seems better than disregarding velocities entirely because it's hard to perfectly represent them. Sometimes perfect is the the enemy of good!

• On the Mac Command+Shift+click appears to be available
• Option click too ... but its use could preclude MuseScore from supporting copy-drag in the future —something I'd like to see.

scorster

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