Note Preview isn't taking into consideration the velocity
When the user clicks a note-head, there is a preview (sound) of the note's pitch. This most definitely should also preview the note's velocity. If one is working on a score in PPP and clicks on a note, the user will get an un-pleasant loud tone, and this especially is apparent in certain soundfonts that have loud jumps between different velocity layers. Although one could argue that it's just a preview, it wouldn't be much to have it take into consideration the dynamic already in place or the actual note's velocity set in the inspector, and i can't think of a good reason not to do this. Please fix this in the future.
To be sure, note "preview" also incorporates the tuning, so if I change a note to be -50 in tune, the preview will actually play this back: just another reason why velocity should also be involved. I consider this to be a bug, but it's filed under a feature request.
Ciao.
Comments
The sound, pitch and tuning though are always individual settings, so easy to get to. The velocity is only easy to get to if set explicitly to that note, using mode User.
If the velocity of a note is not set explicitly, but derived from some dynamic earlier in the score, or set to mode Offset, this would mean we'd have to render the entite stafes's sound on every note entry, so this probably would cause a performance issue, see also the discussion in #12971: Same note in different voices and lengths plays only the length of the shortest note, esp. comment #38
Hrm. If it can't be programmed efficiently enough to be unnoticeable time-wise, maybe a user-setting somewhere in preferences could allow the user to set the default velocity of note-preview or actually have it be saved to the score somehow depending on what soundfonts are used.
My sense is that the code needed to get a velocity is fast enough that this wouldn't be an issue, whereas the code involved in that other issue might be more so. Just guesses though.
I'd also like to point out that there is at least one reason *not* to do this, though. Some people really rely on that playback to make sure they entered the right note. And you might not want to have your speakers turned up loud enough to actually hear a note at "ppp" well - doing so would make "fff" notes unpleasant to hear during note input. I suspect I would actually prefer consistent volume, given a choice. Although I can certainly see both sides.
+1.
Taking into consideration that the user might want consistency, an option in preferences would seem to be a good middle-ground: Let note-preview be either a given velocity programmable by the user but set to a default mf or whatever it is, or let it follow the current or immediate velocity in the staff/on the note. If that could be done tastefully,...