My Kickstarter purchase arrived this morning (almost two years past the estimated delivery date). So, hey! It’s a real product now. We should include it here.
Build quality is rock solid. And the sensors seem even and responsive, overall. I am very much of the “take your time, get it right” mindset, and on these fronts, I think the delays paid off. (I also love the hard case that they threw in for our patience.)
First impressions of the raw data to follow. But note that there are no docs or downloads on the KMI site yet. Meaning, most of the limits or oddities I mention should be resolveable
Note On messages behave as expected.
I’m not seeing Note Off velocity in my midi monitor. (They mention this on the pamphlet that came with it, so I expected it would be enabled by default. I’m sure it just needs to be turned on.)
(That pamphlet also says the right-hand slider defaults to preset selection, though. It sends CC#1. So, that’s the first thing we learn: pamphlets aren’t to be trusted!)
Z axis (pressure) performs well enough. I imagine there’s a curve to edit in the editor, and I want to do so. High values require a lot of pressure.
Y axis (forwards/backwards)… not sure.
It does send this on CC#74 as expected, so that’s good.
It defaults to absolute position within each key. So, the space next to 0 on a black key is roughly 48 on a white key. I can’t decide whether or not that’s as it should be. (My natural fingering on a C minor triad has the C and Eb at similar values, which is a pleasant surprise. But then the G ends up significantly higher based on piano ergonomics. I could practice a more even playing style, but I’m not sure that’s healthy).
My instinct says that absolute position is appropriate for something like the Haken Continuum, but that it has no place on a piano style keyboard, much less one with discrete keys of varying height. But I’m sure the editor has a mode which outputs numbers relative to your initial placement. And if it doesn’t, the data provided is more than sufficient for me to build my own in max.
Anyway, I usually disable CC#74. With absolute positioning, I send a lot of unintended values just by placing my hand. And even with relative, I make involuntary changes while sliding in X. I think that will be different here, because my relationship with the X axis is so unlike other MPE controllers. So, I might suddenly care about Y. That’s interesting.
Moving on!
X axis (pitch bend)… is garbage.
Part of that is just me being opinionated. There’s no continuous sliding from one key to another, which I make extensive use of on other controllers. So, I was never going to be happy with whatever it gives me. Strong bias. Acknowledged.
But, I’ve had time to get over that. (I had an implementation thought a few months ago which would necessitate disabling per-note bend anyway, and this is a good controller to explore that on.)
It’s still garbage, though.
Default behavior is that one of the sliders controls bend range, so if you’re using this melodically, your one-finger bend becomes a two handed gesture. And I’m cool with that. It’s probably the best compromise we’re gonna get.
Except…
I think they might be artificially limiting the max range. Can’t tell for sure, because for one reason or another, it’s snapping back to center prematurely right now. Meaning, I strike a note and bend it in either direction, and it doesn’t hold where I hold it. The moment I stop bending further, I’m not bending at all.
(I think what’s happening is the sensor registers my finger as switching from one key to the next, and thus performs the release action of snapping back to center.)
That… doesn’t seem like an editor thing. That seems like a firmware update.
So, yeah. This data isn’t usable. Ergo, garbage.
Anyway, I fully expect every part of this post to be rendered invalid soon, but it’s an interesting snapshot regardless, which can serve as a placeholder for further discussion as these issues are resolved.