User velocity does nothing

I encountered this, too.

Both user and offset velocity settings work as expected for me on instruments that don't use single note dynamics. For instruments that do use single note dynamics, I'm not exactly sure what I expect, but I do think I know that velocity has little to do with volume on that case, more about initial attack only. For such instruments, though, I don't see an obvious different in behavior here between offset and user. That is, a flute note at mf (default velocity 80) continues to sound mf whether I set user velocity to 1, or offset to -79.

As far as I recall it's been that way since the beginning of single note dynamics, certainly it was that way at first. Maybe there were a couple of releases in there where velocity did somehow affect volume even with SND?

Anyhow, since you say you hear a different between user & offset, we must be doing something different. Can you attach a score and steps to reproduce a problem?

I'm not getting why SND seemingly puts user velocity control out of business. Pretty much all instruments are SND-enabled now, no? Why does velocity control of individual notes conflict with that?

I don't know that is has to be this way, and I'll let TheOtherJThistle speak to whether it's feasible to not do this. But I can provide some historical context.

"Velocity" comes from the world of keyboard synths, where it is literally how you measure how hard someone pressed a key (the time it takes for the key to get from a sensor at the top to a sensor at the bottom). In the original days of MIDI, that was basically it - velocity was the one and only way to control the volume of a note. Hit a key harder, get a louder note. But velocity info is transmitted only once, when the note is first hit. So there was no way to have the volume change afterwards. Well, no way the user could control, anyhow - obviously piano and other sounds might decay on their own. So, someone came up with the idea of sending send separate MIDI messages (called "continuous controller" or CC messages) after the initial note to control the volume. But not all implementations support that model.

If you do support SND, the volume is thus mostly controlled by CC, but the initial velocity is used to select which sample gets used in the case of instruments sampled at different "velocities". For example, a Rhodes electric piano sampled with a soft attack and hard attack), but the CC message controls the volume. But, I gather some implementations might use this "velocity switching" for something entirely different - like to use different samples for slurred versus tongued notes for strings and winds, or different stick/mallet types for percussion, or who knows what else. So in an implementation where you are using CC messages to control volume, you can't necessarily assume velocity actually is related to volume at all.

Except, maybe we can, because shoot, it's our implementation. That's where things get super fuzzy for me. I don't know if there is some technical reason why one cannot use initial velocity to also set the volume. Maybe that would affect other notes already being sustained, since CC messages are per channel rather than per note. That seems plausible. Or maybe it's just inconvenient to code it that way given the current realities of our algorithms and data structures.

I do remember this having come up as an issue with 3.1, and there either was or was not a solution found. If there was and it stopped working, that could be related to the same change that apparently broke some things about accents. Or it might be it's really been this way since 3.1 and there really is no good solution in the near future.

I had a note in my score that I thought was too loud. I wanted to make it softer. Couldn't. Is that in any way right? Another scenario is compensating for unison collisions. How can this be right?

I'm not saying it's a good thing, but assuming you read through that history, hopefully you at least understand why that is the case based on the constraints of how MIDI works. A workaround would be to turn off SND for that instrument. Maybe someone else knows of some clever way to coerce SND into doing what you want.

User velocity works with CC11.

So if I adjust the instrument to use CC11 (is that in the synth settings?) I can set velocity?

Maybe the velocity change slots should be greyed out if not supported for a particular instrument (and it is more fundamental than just a bug)?

CC11 is a synthesizer setting and affects all instruments. It makes SND work for all supported instruments as well as user velocities in nearly all sound fonts but makes expressive sounds in the MuseScore_General_HQ sound font not work.

Great. Thanks. Why is this not considered more pressing, that the ability to adjust note volumes has been removed by accident?

To my knowledge user velocity never worked with CC2

If you read my historical background carefully, you will better understand the technical reasons why in some sense velocity is inherently incompatible with SND. There might be hacks to get it to work, but as I noted, it likely wouldn't work the way you want or need, because CC messages are per channel, meaning if you make one note softer or louder via velocity, then as far as I know all notes currently sounding on that channel would be affected.

Maybe MIDI 2.0 includes something we would be able to take advantage of in MuseScore 4. MIDI is not really my specialty, but I have been around it and doing some programming around it since practically day one, so I'm better at talking about generalities than specifics.

.

Every single midi note-on contains a velocity. This is now inoperative/ignored? Can Sibelius or Finale control the volume of a single note? I can see that setting the initial velocity of a note that has internal dynamic changes can present problems, but most notes DON'T. Removing the ability to control individual notes is no solution. If it's no longer supported, remove it from the UI.

Can a plugin set the note velocity?

Velocity is not ignored, it just no longer controls volume, for the reasons I tried to clearly explain already - when using SND, volume is controlled by CC messages, not by velocity. So in theory, velocity will control which sample gets used, but it won't control the volume, if SND is enabled, because that is fundamentally the difference between supporting SND versus not. Plugins can presumably control velocity in the same way the Inspector can, but I doubt setting velocity from a plugin will change the basic fact that in the SND, velocity simply is not the same as volume.

Whether there is a way to hack the MIDI specification in order to override this is something I have no insight into. Might be something to take up on a MIDI-specific forum, if people there have good suggestions for us as to how to resolve this conundrum, feel free to point us to their answers.

I see. Does anyone have Finale or Sibelius or whatever, who can see how they deal with this? This clearly needs user documentation.

In the case I had, I had a divisi in a choral score. Won't work.

@BSG , @sr3323 - this may be a bit technical, but this is why single-note dynamics doesn't work with note-specific velocities:

We control single-note dynamics with CC messages. These are messages that are sent to the synthesizer, and in this case they tell it how loud to make the playback. We use CC messages because they can change how loud a note is in real time.

The problem is that the soundfont is setup to interpret these CC messages as 'change the volume of the channel'. The channel is the synthesizer's name for an 'instrument'. So, if our CC messages are changing the volume of the whole channel, there's no way individual note volumes can be controlled.

There are plans, I hope, to use something called 'polyphonic aftertouch' in the future, which does allow note-specific control of volume.

But for now, we can't control note-specific volumes. As far as I can remember, it's always been that way with single-note dynamics.

I understand. The field should be removed or greyed out in the inspector for SND instruments. There should therefore be a way to set the channel volume (via CC), for the whole channel, at a point in the score with the inspector without introducing a "Dynamic" mark, hacking it, and hiding it, even if the velocity of individual notes is no longer meaningful.

These work when you use CC11 so they shouldn't be grayed out.

So shouldn't it be greyed out if you don't?

A conditional gray out would be fine.

> There should therefore be a way to set the channel volume (via CC), for the whole channel, at a point in the score with the inspector without introducing a "Dynamic" mark, hacking it, and hiding it, even if the velocity of individual notes is no longer meaningful.

What?! Why? What's wrong with introducing a dynamic mark and just setting it to be invisible?

It is unappealing. You need another one to revert it, and that requires knowing and duplicating the regnant dynamic prior to it, something which, by the way, is impossible to determine but by eye (esp difficult in light of hidden dynamics, as it were) in MuseScore. And if you ever change that, you'll be in a pickle unless you find all of these. It is awful and a nursery for errors.

I feel this sort of fine co tell over the playback is the sort of thing that will be addressed by t sequencer in MuseScore 4, no need to reproduce this effort in the Inspector.

But, a note on velocity and SND - shouldn’t velocity still affect the initial attack, by allowing the synth to choose the proper sample? For example, if middle “C” on trumpet is sample at three different dynamics and mapped to three different velocity ranges, this should be something the Velocity field In the Inspector could still co troll. Right now, though, I’m not convinced velocity is used at all for this purpose.

I create Virtual Instruments (both SFZ and SoundFonts: sf2, sf3) and I can confirm there is nothing to do, this is a feature, not a regression. The professional VST called Kontakt Player works exactly this same way. I will tell you why and explain what to do – basically you want to change your virtual instrument, not Fluid or Zerberus – the players in MuseScore.
- Virtual instruments are a bunch of audio samples configured to be played in function of what note is pressed, at which velocity etc..
- CC messages are MIDI messages for continuous change of sound, works for the whole MIDI track.
- Polyphonic Aftertouch (a feature not yet implemented in MS, should be in the near future, I hope) has the same idea of CC messages, but works for individual notes instead of whole tracks only.
- When you create a virtual instrument, there are some things set up by default:
· the velocity is by default configured to control two things: the volume of the output note and the cutoff of a low-pass filter to simulate better the physical response of almost all instruments;
· both CC2, called volume, and CC11, called expression pedal, are configured to control the volume of the whole track, but without any filtering;
· CC10, pan, is configured to change the stereo pan;
· etc..
- However, we can separate instruments in two categories: the percussive ones (without Single Note Dynamics or SND) and continuous ones (with SND).
- For the percussive ones, like piano, the velocity should control the volume of the note and apply a low-pass filter, which is the default. In the best scenario, you have different samples for different velocities and you can use several velocity layers.
- For the continuous ones, you have to do a manual setup for them to work with CC2, called breath controller, – you can make CC2 change not only the volume, but also the filtering, making the physical response much more accurate. You can even use multiple layers in CC2 as well.
- If you make your samples respond to CC2, you have to deactivate their response to velocity, by making the velocity not affect the volume or the filtering. Why? Because CC2 is continuous and velocity is only one per note – so, if you don't do this, then you end up having two controls of different natures controlling the output volume. Then, for example, if you have a long note with p < f, you have: the velocity saying "low volume for the entire note" and CC2 saying "start the note with low volume and increase it" – then it will sound actually like ppp < mp instead. And if you have the opposite, f > p, the velocity setup says "high volume for the entire note" and CC2 says "start loud and go to quiet". Then it will sound like fff > mf. This is why the Virtual Instrument creator has to manually deactivate velocity response, so that f > p actually sounds like f > p and p < f like p < f.
- Shouldn't velocity be grayed out for SND instruments? No. Why? Virtual instruments of better quality can have multiple samples playing simultaneously. The best setup for them is to have long samples configured to work with CC2 and only with CC2 and short attack samples to respond to velocity and only to velocity. Then you end up with a lot more control – you can use the velocity to control the attack and CC2 to control the dynamics of the long samples.

This is a complex subject and I had to write all this to explain a bit, my suggestion is to download Polyphone (free SounFont editor) and try those things yourself.

I'm preparing some virtual instruments with this complete setup and I hope to share them with the community when I manage to get a "version 1.0".

My suggestion to what should be added in MuseScore though is a possibility to manually edit CC messages, like @TheOtherJThistle said. This could be a curve editing tool attached to the Piano Roll.

(In response to Marc Sabatella • Aug 11, 2020 - 18:23)
Definitely it worked that way at the beginning of single note dynamics, and it was way better, at least as a default setting.
The expected result is that the start (attack) intensity responds to velocity, this is the standard behavior of almost all MIDI keyboards if no special assignation is given to velocity. And when I say "intensity" I mean all the factors that are associated with intensity, for instance any filter in the model of the sound whose parameters depend on intensity. It is true that MIDI allows to redirect velocity to many other controls, but it is also true that initial intensity is and has been the main application of velocity. There is no reason why single note dynamics should change that.
So there is a problem if one wants to reduce the intensity of a single note without changing the general dynamic mark, or if one doesn't want to both place an invisible mark and also change the "velocity" value of the dynamic mark.
In my usage case there is still another problem. For some reason the A5 in the flute is louder than the Bb5, so, as a workaround, I attempted to apply a negative offset velocity, to no avail. This is how I discovered the problem. So, to solve the inconsistency I should apply a workaround of the workaround... which seems a bit awkward...!
It should also be noticed that changing the velocity does work when one changes the value of the dynamic mark. For instance, mf, which has velocity = 80 by default, sounds much softer if velocity is changed to 40, for instance.
I find this an inconsistent interpretation of what velocity is.

(In response to TheOtherJThistle • Sep 2, 2020 - 09:43)
What you say doesn't seem to agree with the fact that the velocity indicated in the inspector window for dynamic marks really sets the initial intensity of the note, so it is perfectly possible to make initial velocity coexist with initial velocity, as it also happened with the first version of single note dynamics.

(In response to Ludwig van Benteuer • Mar 27, 2021 - 18:34)
How do you explain that dynamics, for which a velocity is specified, do work as expected?
So if I need a note-on at -25 (which means 25 % less than the indicated dynamics) I just calculate 0.75*(current dynamics velocity) and place an invisible dynamics mark right below the note with that velocity and a second invisible dynamics mark below the next note with the original velocity. Isn't this cumbersome?
Besides, there is no logic in this "design decision" of disabling the possibility of changing the intensity of a single note at its onset. Velocity is a property of note on events, CC2 is a control change whose first value may well be set coincident with (or equivalent to) the velocity stated in the note-on message.
Otherwise single note dynamics is useless. In a minimally realistic render you need to tweak almost every note tempo and dynamics. If you can't or must add two dynamic marks per note to circumvent the problem, then there is something fundamentally wrong. Single note dynamics without note-on velocity control is like having golden plates but no food to fill them with.

Everything about dynamics and velocity has changed for MuseScore 4, so I encourage you to download a nightly build and see if it meets your needs. If you have feedback, please report it on GitHub as per the beta announcement.