indeed, the player is a factor.
id like to see this app for guitar players, i know a couple that would only fill in one velocity.
they would just say the app was broken tho...
i had to blow on windsynth for a good 5-10 minutes before i had em all filled and that required playing a wide variety of stuff.
it was nice to see because i had in my head that wx5 only send 2 velocities and does all the rest by breath control and so i programmed patches with that in mind but a ways back i started noticing that wasnt the best sound and started programming more velocity stuff that was working better than it should if theres only 2 levels.
oops.
Midi Keyboard Velocity Test
-
- KVRian
- 1480 posts since 14 Jun, 2003
-
- KVRAF
- 3441 posts since 15 Mar, 2003
I agree that it isn't the best test.
I had to spend quit a while to get the results I did.
I eventually just gave up trying to get the last 3.
Other people may quit earlier and miss some velocities.
I had to spend quit a while to get the results I did.
I eventually just gave up trying to get the last 3.
Other people may quit earlier and miss some velocities.
-
- KVRAF
- 4141 posts since 11 Aug, 2006 from Texas
I have a non-standard keyboard; C-Thru Music's Axis-49. Given the short throw on the keys I'm not really surprised there were so many gaps. I pressed keys for about 10 minutes and never got any of the missing values.
-
- KVRist
- 498 posts since 9 Jul, 2008
KVR wrote:EVERYONE, TEST YOUR KEYBOARDS OUT.
*bad results*
KVR wrote:THE TEST IS FLAWED!
-
- KVRAF
- 2310 posts since 13 Apr, 2008 from Germany
This thread is very necessary... I do not need to test my Emu X-Board, I know that there are massive velocity issues...
If you don't get some midi values that can be a hint that the maker does some value scaling inside the board but the key sensing itself does not offer enough resolution to do so without precision issues. I guess practically one or two missing values are no big deal so. To make tests more usable I would suggest that you first check with the boards internal velocity curve set to linear or neutral setting, then with other settings you prefer using.
However, make sure that you use midi scaling filters in your host with care as these always leads to missing values. That applies not only to velocity but all other controller values too. Avoid cascading those filters... that can be a disaster...
A board I'd really like to check out is the Infinite Response VAX 76. On paper it promises magic, 14bit midi velocity output - hence enough resolution and headroom for any scaling to the usual 7 bit resolution one might prefer... A great board with many other great properties - just horribly expensive...
Only alternative - become an organ player as you do not need velocity sensitive keys for that... just early contact point and waterfall keyshape
If you don't get some midi values that can be a hint that the maker does some value scaling inside the board but the key sensing itself does not offer enough resolution to do so without precision issues. I guess practically one or two missing values are no big deal so. To make tests more usable I would suggest that you first check with the boards internal velocity curve set to linear or neutral setting, then with other settings you prefer using.
However, make sure that you use midi scaling filters in your host with care as these always leads to missing values. That applies not only to velocity but all other controller values too. Avoid cascading those filters... that can be a disaster...
A board I'd really like to check out is the Infinite Response VAX 76. On paper it promises magic, 14bit midi velocity output - hence enough resolution and headroom for any scaling to the usual 7 bit resolution one might prefer... A great board with many other great properties - just horribly expensive...
Only alternative - become an organ player as you do not need velocity sensitive keys for that... just early contact point and waterfall keyshape
Best regards, TiUser
...and keep on jamming...
...and keep on jamming...
-
- KVRAF
- 9528 posts since 6 Oct, 2004
If you don't mind, what synth(s) were you playing for the test?Tony Ostinato wrote:indeed, the player is a factor.
id like to see this app for guitar players, i know a couple that would only fill in one velocity.
they would just say the app was broken tho...
i had to blow on windsynth for a good 5-10 minutes before i had em all filled and that required playing a wide variety of stuff.
it was nice to see because i had in my head that wx5 only send 2 velocities and does all the rest by breath control and so i programmed patches with that in mind but a ways back i started noticing that wasnt the best sound and started programming more velocity stuff that was working better than it should if theres only 2 levels.
oops.
And which are your favorites with the wx5?
Cheers
-
- KVRist
- 369 posts since 13 Jun, 2006 from Cornwall, UK
Excellent thread this 
And very timely for me too - I've only just contributed some thoughts to Sound On Sound on choosing which MIDI velocity curve you should use with your controller keyboard:
www.soundonsound.com/sos/jun10/articles/qa0610_3.htm
I'm not sure about this - surely the whole point of MIDI scaling filters (or in this case 'velocity curves') is to ensure that you can play whatever keyboard you have with the maximum amount of expression, by making sure it ends up outputing over the entire MIDI velocity range?
I don't see that a MIDI velocity curve will automatically lead to missing values unless you abuse it.
Enlighten me!
Martin
And very timely for me too - I've only just contributed some thoughts to Sound On Sound on choosing which MIDI velocity curve you should use with your controller keyboard:
www.soundonsound.com/sos/jun10/articles/qa0610_3.htm
Hi TiUser!TiUser wrote:However, make sure that you use midi scaling filters in your host with care as these always leads to missing values. That applies not only to velocity but all other controller values too. Avoid cascading those filters... that can be a disaster...
I'm not sure about this - surely the whole point of MIDI scaling filters (or in this case 'velocity curves') is to ensure that you can play whatever keyboard you have with the maximum amount of expression, by making sure it ends up outputing over the entire MIDI velocity range?
I don't see that a MIDI velocity curve will automatically lead to missing values unless you abuse it.
Enlighten me!
Martin
-
- KVRAF
- 2310 posts since 13 Apr, 2008 from Germany
I said "midi filters" and meant such in an host application.
Your article reference focuses on something different I totally agree with - simply use the velocity curve that suits your playing technique and needs best.
The scaling process I refer to is nonlinear on integral numbers (integers). In the "midi value domain" it always leads to either jumps (missing values in between) or rounding (putting different values to just one). In that sense it is a data loss - a result of less than the initial 128 potentially available value steps where some values in the range are missing then and resolution gets more coarse.
The only way to project all 0..127 -> 0..127 in a useful way without this loss is linear. Let's explicitly exclude funny things like inversion or randomly assigning each one to any other where no values might be lost but are inappropriate for normal uses.
Scaling inside the keyboard - before values are put into the midi range 0..127 - can work better if the internal numerical velocity resolution is higher or the curves are archived internally in other ways than digital numerical scaling. With this you can maintain all 128 steps for all curves - just the way you have to strike the keys to get them changes.
Limited input can also not create more data values, you can just scale them up. Again this is useful - but not ideal either, even with scaling you do not get all values, some in between are missing.
Think of image processing and adjusting color curves - similar problem when the original image is a standard 8bit / channel file. If you do hefty corrections you get some very obvious tone separation or posterize effect.
Scaling in the "midi value domain" is not useless but should be applied with care not to get too obvious reductions of used values in the range - unless you intentionally want strong effects.
Coming back to the article you can't really afford to lose values in the 0..127 midi range - especially if you really have so many layers - or maybe a quasi continuous responding synth.... anyway, the cumbersome problems in the article with response in lower or upper range of velocity values can well be a problem with too extreme midi velocity curves too... and if you don't understand what to look for the analysis tools will not help nailing and fixing the issue.
I hope this was not too confusing.
Your article reference focuses on something different I totally agree with - simply use the velocity curve that suits your playing technique and needs best.
The scaling process I refer to is nonlinear on integral numbers (integers). In the "midi value domain" it always leads to either jumps (missing values in between) or rounding (putting different values to just one). In that sense it is a data loss - a result of less than the initial 128 potentially available value steps where some values in the range are missing then and resolution gets more coarse.
The only way to project all 0..127 -> 0..127 in a useful way without this loss is linear. Let's explicitly exclude funny things like inversion or randomly assigning each one to any other where no values might be lost but are inappropriate for normal uses.
Scaling inside the keyboard - before values are put into the midi range 0..127 - can work better if the internal numerical velocity resolution is higher or the curves are archived internally in other ways than digital numerical scaling. With this you can maintain all 128 steps for all curves - just the way you have to strike the keys to get them changes.
Limited input can also not create more data values, you can just scale them up. Again this is useful - but not ideal either, even with scaling you do not get all values, some in between are missing.
Think of image processing and adjusting color curves - similar problem when the original image is a standard 8bit / channel file. If you do hefty corrections you get some very obvious tone separation or posterize effect.
Scaling in the "midi value domain" is not useless but should be applied with care not to get too obvious reductions of used values in the range - unless you intentionally want strong effects.
Coming back to the article you can't really afford to lose values in the 0..127 midi range - especially if you really have so many layers - or maybe a quasi continuous responding synth.... anyway, the cumbersome problems in the article with response in lower or upper range of velocity values can well be a problem with too extreme midi velocity curves too... and if you don't understand what to look for the analysis tools will not help nailing and fixing the issue.
I hope this was not too confusing.
Best regards, TiUser
...and keep on jamming...
...and keep on jamming...
-
- KVRist
- 369 posts since 13 Jun, 2006 from Cornwall, UK
Hi TiUser!
And thanks for your very detailed reply
Anyone care to prove this by re-testing their keyboard after changing it to a different velocity curve setting, to see if these 'dead spots' move to other values or even disappear at the default 'linear' setting?
Fascinating stuff, and not confusing at all!
After all, getting the maximum expression out of our keyboards is a vital part of the musicial process for many people
Martin
And thanks for your very detailed reply
In essence we're both in total agreement here, except that I didn't make any distinction between hardware and MIDI software scaling in that link, because I wasn't convinced they end up differentTiUser wrote:I said "midi filters" and meant such in an host application.
Your article reference focuses on something different I totally agree with - simply use the velocity curve that suits your playing technique and needs best.
Ah, now this is new to me - I haven't come across talk of higher internal velocity resolutions before, and if this is what keyboard manufacturers do then tweaking your velocity curve in your keyboard should indeed give you a smoother response with no 'dead spots' than using a host MIDI mapperScaling inside the keyboard - before values are put into the midi range 0..127 - can work better if the internal numerical velocity resolution is higher or the curves are archived internally in other ways than digital numerical scaling. With this you can maintain all 128 steps for all curves - just the way you have to strike the keys to get them changes...
I know exactly what you mean here about missed steps and rounding errors, but having thought through things again I suspect this is why so many people here are finding missing steps in their velocity - these results suggest that these keyboard's own velocity curves modify the MIDI data once it's already in its 0-127 range, thus giving rise to the 'dead spots'.The scaling process I refer to is nonlinear on integral numbers (integers). In the "midi value domain" it always leads to either jumps (missing values in between) or rounding (putting different values to just one). In that sense it is a data loss - a result of less than the initial 128 potentially available value steps where some values in the range are missing then and resolution gets more coarse.
Anyone care to prove this by re-testing their keyboard after changing it to a different velocity curve setting, to see if these 'dead spots' move to other values or even disappear at the default 'linear' setting?
Fascinating stuff, and not confusing at all!
After all, getting the maximum expression out of our keyboards is a vital part of the musicial process for many people
Martin
-
- KVRAF
- 2310 posts since 13 Apr, 2008 from Germany
Glad that this helped.
What midi keyboard makers finally do inside isn't really revealed to us. But it's the only chance to set curves without losing midi output accuracy. With midi curves you always do.
I own an Emu X-Board which is a good example for a bad example in velocity response There are two adjustable internal timing constants affecting velocity and several really freaky curves inside the keyboard. Not sure if these curves can be edited - so I didn't find anything in the software that comes with it. The final output resolution isn't a winner... The factory settings of the timing constants give you some heavy action. If you reduce them to get lighter response accuracy seems to become worse already inside.
Long story short conclusion - if you already get bad resolution from the board - heavy lifting with chained midi velocity filters can't make it a winner. It's just emergency lifting to fit it in the max bounds.
I also have a PCR and never felt I needed dramatic adjustments. Also it's somehow soft it responds well in terms of velocity values.
To my feel the Emu also responds different on white an black keys... while I didn't have that feel with the PCR. Interesting to see as well that the new Fatar numa series provides two curves - one for the black keys and another for the white ones...
Sensing midi velocity values itself is an interesting topic too. The usual approach is really to meter the time delay between a contact 1 and contact 2 - which somehow corresponds to an assumed constant force or velocity the key is moved while striking a key. But there are some doubts - especially referring to hammer action - that this is accurate enough to make it feel really well - because it doesn't meter what's exactly happening between these two contact points. It's just ok if you assume constant speed - it's just the question if this is the case... In simpler words the energy you swing the key with could be a better value for velocity. Unfortunately sensing this is much more complicated and I know only one board that claims to do something like this: the extremely expensive infinite response VAX 76. BTW this has some more bells and whistles like polyphonic(!) aftertouch. Wished a really great player could check one out and tell us if it's a real difference.
What midi keyboard makers finally do inside isn't really revealed to us. But it's the only chance to set curves without losing midi output accuracy. With midi curves you always do.
I own an Emu X-Board which is a good example for a bad example in velocity response
There are two adjustable internal timing constants affecting velocity and several really freaky curves inside the keyboard. Not sure if these curves can be edited - so I didn't find anything in the software that comes with it. The final output resolution isn't a winner... The factory settings of the timing constants give you some heavy action. If you reduce them to get lighter response accuracy seems to become worse already inside.Long story short conclusion - if you already get bad resolution from the board - heavy lifting with chained midi velocity filters can't make it a winner. It's just emergency lifting to fit it in the max bounds.
I also have a PCR and never felt I needed dramatic adjustments. Also it's somehow soft it responds well in terms of velocity values.
To my feel the Emu also responds different on white an black keys... while I didn't have that feel with the PCR. Interesting to see as well that the new Fatar numa series provides two curves - one for the black keys and another for the white ones...
Sensing midi velocity values itself is an interesting topic too. The usual approach is really to meter the time delay between a contact 1 and contact 2 - which somehow corresponds to an assumed constant force or velocity the key is moved while striking a key. But there are some doubts - especially referring to hammer action - that this is accurate enough to make it feel really well - because it doesn't meter what's exactly happening between these two contact points. It's just ok if you assume constant speed - it's just the question if this is the case... In simpler words the energy you swing the key with could be a better value for velocity. Unfortunately sensing this is much more complicated and I know only one board that claims to do something like this: the extremely expensive infinite response VAX 76. BTW this has some more bells and whistles like polyphonic(!) aftertouch. Wished a really great player could check one out and tell us if it's a real difference.
Best regards, TiUser
...and keep on jamming...
...and keep on jamming...
-
- KVRer
- 20 posts since 5 May, 2008
I get full range from 0 to 127 with my X-Board 49 with the linear velocity curve. Some of the other curves have one or a few more gaps. Not bad at all.
The X-Board is actually semi-weighted, and feels great, just look under the keys and notice the metal plates.
The X-Board is actually semi-weighted, and feels great, just look under the keys and notice the metal plates.
-
- KVRAF
- 2310 posts since 13 Apr, 2008 from Germany
I've just played around with the test program.
What I miss is a statistics how often each velocity value has been hit.
Maybe this can be added?
It would be useful to have this as vst plugin too.
Besides, I am shocked how worse all my keyboards seem to respond - many holes here and there. Also repetitively producing certain values is nearly impossible. With DX7ii nearly nothing above 100. The Edirol seems to be still the best, so it has more and more holes on the upper velocity range... confirms the sheet another poster has sent.
Just to add it would be also interesting how difficult you found it to reproduce certain velocity values and how much the ones you get are spread around the value you want to get. Indeed if a keyboard would just randomly sprinkle values a sheet covering all numbers would mean nothing...
What I miss is a statistics how often each velocity value has been hit.
Maybe this can be added?
It would be useful to have this as vst plugin too.
Besides, I am shocked how worse all my keyboards seem to respond - many holes here and there. Also repetitively producing certain values is nearly impossible. With DX7ii nearly nothing above 100. The Edirol seems to be still the best, so it has more and more holes on the upper velocity range... confirms the sheet another poster has sent.
Just to add it would be also interesting how difficult you found it to reproduce certain velocity values and how much the ones you get are spread around the value you want to get. Indeed if a keyboard would just randomly sprinkle values a sheet covering all numbers would mean nothing...
Best regards, TiUser
...and keep on jamming...
...and keep on jamming...
-
- KVRist
- 35 posts since 14 Jan, 2008 from French Polynesia
Hi All!
- With any DAW or MIDI Monitor, Record your keyboard MIDI output as a Standard MIDI File : play at least 2000 notes in order to get a good probability of covering the "input velocity" dynamics with, say, 1 % resolution. Use a filter to record only Note On messages.
- Convert the SMF into text with any MIDI to Text converter (MIDI-OX can directly generate the text file from the MIDI Input).
- Import the text file into a spreadsheet (e.g. OpenOffice.org Calc), remove all columns except the data2 one (velocity).
- Use the frequency function of the spreadsheet to compute and display the histogram of this column.
See also Histogram.jar that directly displays the Note On histogram of a given SMF.
So, the missing codes are not caused by low quality AD converters, but the result of software scaling and rounding, in the time interval conversion into a MIDI Velocity value, according to the desired curve.
Alain
A solution I used before knowing the VelocityChecker program:TiUser wrote:What I miss is a statistics how often each velocity value has been hit.
- With any DAW or MIDI Monitor, Record your keyboard MIDI output as a Standard MIDI File : play at least 2000 notes in order to get a good probability of covering the "input velocity" dynamics with, say, 1 % resolution. Use a filter to record only Note On messages.
- Convert the SMF into text with any MIDI to Text converter (MIDI-OX can directly generate the text file from the MIDI Input).
- Import the text file into a spreadsheet (e.g. OpenOffice.org Calc), remove all columns except the data2 one (velocity).
- Use the frequency function of the spreadsheet to compute and display the histogram of this column.
See also Histogram.jar that directly displays the Note On histogram of a given SMF.
I tested my Edirol PCR-800 too. Interestingly enough, I got exactly the same results as jensa above with the 3rd Velocity Curve (Linear Heavy), except for Velo 119 I could'nt obtain.The Edirol seems to be still the best, so it has more and more holes on the upper velocity range... confirms the sheet another poster has sent.
So, the missing codes are not caused by low quality AD converters, but the result of software scaling and rounding, in the time interval conversion into a MIDI Velocity value, according to the desired curve.
Alain
-
- KVRAF
- 2310 posts since 13 Apr, 2008 from Germany
Hi and thank you for the idea to statistically analyze.
To seriously check things like repetition accuracy of single keys would need some more scientific evaluation as I am not able to hit a key perfectly the same for many many times. Just covering a range can also be obtained by sprinkle of somewhat random values either.
Just to note, there is no AD conversion with the keyboard keys anywhere, that's just metering times between closing contacts at two different positions. Some other controls of course need AD like AT, MW, pitch, pots, faders and wheels.
I don't think the PCR's are bad as they feel quite OK when played. However I don't think it is a precision controller either. Rubber contacts have benefits, they are resistant to dust and comparably reliable at a low cost point but need probably regular replacement to keep things adjusted.
To seriously check things like repetition accuracy of single keys would need some more scientific evaluation as I am not able to hit a key perfectly the same for many many times. Just covering a range can also be obtained by sprinkle of somewhat random values either.
Just to note, there is no AD conversion with the keyboard keys anywhere, that's just metering times between closing contacts at two different positions. Some other controls of course need AD like AT, MW, pitch, pots, faders and wheels.
I don't think the PCR's are bad as they feel quite OK when played. However I don't think it is a precision controller either. Rubber contacts have benefits, they are resistant to dust and comparably reliable at a low cost point but need probably regular replacement to keep things adjusted.
Best regards, TiUser
...and keep on jamming...
...and keep on jamming...
-
- KVRist
- 35 posts since 14 Jan, 2008 from French Polynesia
Thank you for the remark! "AD" must be taken here in the general sense - I did not say "voltage to digital"...TiUser wrote:Just to note, there is no AD conversion with the keyboard keys anywhere, that's just metering times between closing contacts at two different positions. Some other controls of course need AD like AT, MW, pitch, pots, faders and wheels.
Sure! I bought it mainly for its light weight and good control set, especially for organ VSTs (VB3)I don't think the PCR's are bad as they feel quite OK when played. However I don't think it is a precision controller either.