need for larger velocity scales, 0-128 to small

[Akos Janca]

Finally, an interesting thread.

Similarly to vEddY's idea I think we need a kind of "user velocity curves". For example Kronos would ask us to make a velocity calibration ("play ppp", "OK", "now play pp", OK etc.) then would make an optimized curve automatically. This curve could be saved with any name and could be edited, too, if needed. More curves could be created and saved.

[jimknopf]

Nice idea: like it!

[EvilDragon]

That's how Kawai MP5 is doing it... automatically.

[peter_schwartz]

Not sure that the idea of playing PPP, PP, P, etc. would work to allow people to calibrate velocity curves because these are all subjective dynamic markings. For starters, the intensity of any one of them, say, mF, would be subject to the setting of the volume control on the unit itself. Yes, it's a pedestrian example, but it's the one control that throws all notion of what any one dynamic marking is right out the window.

Not all composers use the same range of dynamic markings. Tchaikovsky often used dynamic markings of pppp. And while you'll never find that marking in Mozart, that doesn't mean that some passages won't be played with an equivalent dynamic of pppp when performing his music.

And because all music is subject to interpretation, one person's sense of "pppp" might be another person's idea of "ppp". If you take the other extreme, how much louder can ffff be than fff? And what velocity range would you assign to ffff as opposed to fff or ff? Should the difference be 1 velocity step? Maybe 2? Three? Four? Eight? When you come right down to it, it's very hard to quantify any of these things.

Still, as I said above, whenever you start altering a velocity curve of 127 steps to accommodate a different sense of touch, you immediately reduce the resolution of that curve. So while I like the idea of user-adjustable velocity curves, the reality is that you can only decrease the resolution when you alter what starts out as a linear curve.

Food for thought...

[StephenKay]

Still, as I said above, whenever you start altering a velocity curve of 127 steps to accommodate a different sense of touch, you immediately reduce the resolution of that curve. So while I like the idea of user-adjustable velocity curves, the reality is that you can only decrease the resolution when you alter what starts out as a linear curve.

Actually, as long as you are not dropping points from the table, then you would be decreasing resolution in one range while increasing resolution in another. You're merely shifting the points around, not losing any of them. If you allocated the top 50% of the curve to the top 25% of internal velocity level response, you would be increasing the resolution by a factor of 2 in the upper range, while decreasing it in the lower area.

[peter_schwartz]

Hi Stephen,

Great to get your reply! I think we're talking about exactly the same thing, but I'll defer to you to confirm; I'll be more specific in this post about what I meant by "decreasing the resolution"...

What I had in mind was the notion of creating a curve that started out, say, somewhat insensitive in the lower range of values. Let's say that MIDI velocity values of 1 - 51 were mapped to 1 - 31. This would result in a number of adjacent map positions being given the same value; thus, the resolution would decrease in that section.

From map positions 32 to 127 we have 95 positions remaining, but only 75 velocity values to fill them in with, so to speak. This means there will be some areas of the map where velocity values have to be skipped in order to complete the curve, thus making the resolution in that part of the curve "coarse" (low res) here and there. The only way that we complete the curve by not skipping values from 32 on up is to increase the value of each remaining map position linearly until we run out of velocity values, resulting in a curve that ends in a "plateau".

Looking forward to your response,

PS

[StephenKay]

Hi Stephen,

Great to get your reply! I think we're talking about exactly the same thing, but I'll defer to you to confirm; I'll be more specific in this post about what I meant by "decreasing the resolution"...

What I had in mind was the notion of creating a curve that started out, say, somewhat insensitive in the lower range of values. Let's say that MIDI velocity values of 1 - 51 were mapped to 1 - 31. This would result in a number of adjacent map positions being given the same value; thus, the resolution would decrease in that section.

From map positions 32 to 127 we have 95 positions remaining, but only 75 velocity values to fill them in with, so to speak. This means there will be some areas of the map where velocity values have to be skipped in order to complete the curve, thus making the resolution in that part of the curve "coarse" (low res) here and there. The only way that we complete the curve by not skipping values from 32 on up is to increase the value of each remaining map position linearly until we run out of velocity values, resulting in a curve that ends in a "plateau".

This would be true if you were mapping a table of 127 steps to an amplitude engine that only had 127 discrete steps (or directly to MIDI). However, I think we can safely assume that the hypothetical internal tone generators we are talking about here have much higher resolution than that. For the sake of making it easy math-wise, let's stipulate that the tone generator has at least 1270 steps of resolution over the full range of its output (it probably has more if based on floating point...)

The curve would operate on incoming MIDI 0~127, so a linear curve would be mapped such that 1 = 10, 2 = 20, 3 = 30, 4 = 40 ...127 = 1270 as far as what level of the tone generator to play at based on what MIDI value. So if you took my example of making the top 64 values cover only the top 25% of the curve, then it would be:

1 = 15, 2 = 30, 3 = 45, 4 = 60 up to 64 = 9600, (larger steps)
and then
65 = 9605, 66 = 9610, 67 = 9615 up to 127 = 1270 (smaller steps)

So the lower half of the curve loses resolution, while the upper half of the curve gains resolution.
I'm pretty sure this is how it works; the audio engines have a much greater degree of resolution than the 0~127 of MIDI (that's why "smoothing" works).

[peter_schwartz]

Gotcha, thanks for that.

So, speaking generally... what this shows is that it's not enough to just say that MIDI doesn't provide enough steps (values) for velocity. We have to distinguish between mapping MIDI velocity values to form a new response curve, or, leaving the MIDI velocity curve alone (typically linear) and mapping those values within the sound engine to achieve different response curves.

In other words... if we map MIDI velocity values to form nonlinear curves, we're going to lose resolution on the input side. But if we change the velocity scaling in a sound engine as you described it, then a linear map of 127 velocity values can be mapped to a much wider range of response curves within the sound engine itself.

[JimH]

I think what Stephen is saying would be true if the velocity curve were applied at the sound engine and the curve values were mapped after a MIDI note was received. And that might be a good possible way to get better volume resolution without changing the MIDI spec. But I don't think it works this way. I think the curve is applied at the keyboard, and the keyboard can still only output 0-127.

I don't have happen to have a Korg keyboard with an adjustable velocity curve, but I'm using my Yamaha to test with. When I adjust the curve and play into my computer's sequencer/DAW, I can see that it affects the note velocity levels as they are recorded. That's nothing to do with the sound engine. Besides, consider that if the curve were applied at the sound engine, then I decided I wanted to switch to a completely different sound module for my MIDI song that I had recorded, the velocity levels would be all wrong.

So I believe its true that if you change the curve to be anything but linear, you're going to lose resolution somewhere along the curve and you're not going to get it back anywhere.

[jemkeys25]

the keyboard would only ask you to define two velocity values soft ppp,and hardest fff, then calibrate your touch from there, and allow for sonic change along that whole range. it doesn't matter fff, ffff , just your hardest and your softest, which will be different for everyone. well at least the hardest will be different, anyone can strike a note very soft.

[StephenKay]

I think what Stephen is saying would be true if the velocity curve were applied at the sound engine and the curve values were mapped after a MIDI note was received. And that might be a good possible way to get better volume resolution without changing the MIDI spec. But I don't think it works this way. I think the curve is applied at the keyboard, and the keyboard can still only output 0-127.

I don't have happen to have a Korg keyboard with an adjustable velocity curve, but I'm using my Yamaha to test with. When I adjust the curve and play into my computer's sequencer/DAW, I can see that it affects the note velocity levels as they are recorded. That's nothing to do with the sound engine. Besides, consider that if the curve were applied at the sound engine, then I decided I wanted to switch to a completely different sound module for my MIDI song that I had recorded, the velocity levels would be all wrong.

So I believe its true that if you change the curve to be anything but linear, you're going to lose resolution somewhere along the curve and you're not going to get it back anywhere.

Caveat: I'm not a guy that works on the audio engines; I make MIDI do cool stuff. However, I would be very surprised if this is NOT what happens internally on a Korg when you change the velocity response curve in the global Mode.

It could be that we are both correct. Because there is a Pre-MIDI and Post-MIDI setting (on Korgs) as well.

From the OASYS Manual:
Velocity Curve [1…8]
This specifies the way in which the volume and/or tone
will change in response to variations in keyboard
playing dynamics (velocity).

When Convert Position (1–1a) is PreMIDI, variations
in keyboard playing dynamics will affect the velocity
effect and the transmitted velocity data as shown in the
left‐hand diagram below.

Incoming data will automatically use the velocity
curve number 4 shown in the right‐hand diagram.
With a setting of PostMIDI, variations in keyboard
playing dynamics (and in the velocity of incoming
data) will respond as shown in the right‐hand diagram
below. If you are playing OASYS’s tone generator from
an external keyboard or sequencer, and the overall
sound is too bright or too dark, you can set the Convert
Position parameter to PostMIDI and select the
appropriate velocity curve here.

For the transmitted data, the velocity curve number 4
shown in the left‐hand diagram will automatically be
selected.

So what I take that to mean is that, when the setting is Pre-MIDI, it works somewhat as you suggest; whereas when the setting is PostMIDI, it always transmits (to the sequencer) essentially a linear curve (curve 4), and then tailors the velocity response internally (somewhat as I suggest). But in any case, I'd be happy to be corrected by someone (Dan perhaps?) who may know exactly what is happening.

[JimH]

Ah, OK. I wasn't so familiar with the OASYS details. But it looks like they really do that. Since it's a global feature, all they'd need then is to adopt some bigger velocity range internally. So I guess if you were using just the OASYS/Kronos by itself and wanted to adjust the velocity curve you might be better off making it PostMIDI.

Looking at those pictures in the OASYS manual though, I wonder why there are different curves for PreMIDI and PostMIDI. And no convex curves for PreMIDI.

[StephenKay]

The other thing that I've often thought was missing, from these velocity response curves, is the ability to specify a completely "flat" response curve that removes all velocity sensitivity. Many people ask for this. The best way to do this would be to have a setting named "flat" that doesn't select a curve, but allows you to specify a velocity value such as 38, 53, 79, 96, whatever - any value from 1 to 127 - and then whatever you play is transmitted as that value to the program. And then, let's not make it global, let's put the velocity curve in each program and each combi. Let's have a setting that is "Global" (meaning the program/combi uses the global curve), or uses the one you specify in the program/combi.

[jemkeys25]

thats the best idea so far,programmable velocity curves for each program, instead of a global curve.

[JimH]

But there's a problem with that, right? Let's say my piano program is set up with a PostMIDI type of velocity curve, and I record a piano part into my sequencer. (The keyboard has a linear response.) Then I decide that I think my Kurzweil piano would sound better in this part so I switch sounds from the Korg piano to the Kurzweil piano. But it won't sound right because the Kurzweil doesn't have the velocity curve. Not all the velocity information is recorded in the sequenced notes; it relies also on the curve in that one Korg program.