MusicScienceGuy wrote:tweaking the velocity curve to remap the velocity 1 to 33 and the top end down seemed to help
I agree. This is only a problem with certain synths and in some cases patches that have extremely soft response for velocity 1, perhaps outside the range of normal acoustic instrument. Adjusting the patches has helped in these cases, as has mapping pushing up the bottom of the curve using mapping software.
MusicScienceGuy wrote:The key travel issue is probably addressable too - I looked and measured carefully, and it should be possible to lift the rubber gasket switches off the PCB by 0.5-1.0 mm with a plastic sheet with holes in it (easy to create if you have a friend with a laser cutter). With another mm of acceleration distance, one would be able to be a fair bit more nuanced in play - approaching or exceeding a piano's key. So the basic Axis design has a fair bit of room for further refinement (some of which could be done by hobbyists), which is great.
It might be more than just travel depth. I think within the current depth, even without modifications to the keyboard, there is room for improvement. For example, my understanding is the Opal Chameleon has the same travel depth but a completely different key mechanism which is somehow weighted and provides for a lot more control of velocity, although it still takes getting used to. It would be really nice to do a side by side comparison of the two mechanisms. I think this is a major reason to get an Opal over the Axis. (Caveat: I haven't done the said comparison personally and thus can not be sure that its response is that much better, but I suspect that it is based on things I have heard.)
In general velocity sensitive instruments don't actually measure instantaneous velocity on impact but measure the transition time between leaving one contact and striking another (as Yamahas do) or between contact one and contacting another a little bit later (as I think the Axis does).
I think the Axis could be improved by changing the calculation from transition time to velocity by allowing for longer traversal times at the low end, and curving the bottom end there so the mid range response is not affected.
Something like
250ms transition = velocity 1
200ms transition = velocity 2
100ms transition = velocity 10
and then from there up, the normal curve. (These are not actual numbers to use, just to show the general idea.)
I would
really like the exact time-to-velocity map to be user programmable. (By this I don't mean warping the current 127 values as can be done with the velocity mapping application for the 64, I mean actually changing it one step closer to the hardware.) This way we (the user community) could rapidly converge on a set of two or three good, musical presets. Once we had these there wouldn't be a need for user programmability.