MIDI Modifiers Velocity Shift and Compression wrong order

Cubase
,
1

I know, this won’t lead to anything besides people feeling the need to argue and possible not understanding the underlying mechanics. But still, because this feature could be of great use to me and maybe some other people:

in MIDI Modifiers, velocity shift and velocity compression are processed in the wrong order.
I know, in audio compression there’s in gain and out gain, so one could think well there’s only one so either of them might be a valid choice. Here’s what’s wrong with it:

Compression is doing this c(v) = r * v, with v = velocity, and r = rate from 0 to 1 (percentage / 100)

Velocity shift: s(v) = v + t, with t = translation amount

BUT: both functions have a floor (anything below 0 is cut to 0) and a ceiling (v > 127 → v = 127)

So with a compression of 50%, compressed values land in between 1-63.
When shifted upwards for 64, values land in between 33-63.
With a shift of 126 (cubase doesn’t allow 127), it’s always plain 63.

But it is not possible to compress to values between 64-127, or 64-96, or anything like that.
Which would be possible if shifting was applied after the compression.

Also: all of those scenarios would still be possible. And compression values would give more logical and expected results (like 33-63 is compression to 25%, not 50%).

All the scenarios where we want a destination going up to 127 aren’t possible the way it is now.
Changing the order would allow compression to every possible destination range, 16-32 as well as 96-112.

And now that nobody is still reading I’ll add as a bonus that the manual velocity compression in MIDI → functions → velocity … is calculating compression wrong. Not as in there has been made a wrong choice of how it should have been done, but a mistake in the actual calculation.

The function computes an average and the velocity of all selected notes are compressed towards that average like (velocity - average) * compression + average (with compression again being 0…1, or percent / 100)
But the function calculates the average from all notes in the midi part, while the function is applied only to the selected notes in it. Which can result in values way of the correct results, especially when compressing parts that are significantly louder or lower volume than the rest of the part.

cheers

2

MIDI modifiers has more issues by the way.
Range Note Limit should not move all pitches outside the selected range to the upper boundary, only notes higher than the max value. Notes lower than min value should be pitch changed to min value.

3

I’ll mark this as solved since probably noone will want to get behind this anyway, let’s take those features as they are, if they make any sense or none.

4

For what it’s worth, I fully agree on the order of Velocity compression and shift.
I would however replace the “issue” tag with a “feature-request” simply because it is not broken, just not designed in the best way.
Unfortunately I can’t imagine many users use velocity compression these days so it might be hard for such a request to gain any traction.

1 Like
5

Yeah, I don’t think many people use it, too. It could be very useful, it would basically be the same as the hard/medium/soft touch setting on digital pianos. The way it is now you can only have medium/soft/extremely soft, that’s not useful very often.

1 Like