12 Jul
2012
12 Jul
'12
11:02 p.m.
On Thu, Jul 12, 2012 at 09:24:34PM +0200, Atte André Jensen wrote:
I'm trying to use my novation launchpad with
chuck. It seems to be
plug/play, at least I didn't do anything except plug and play :-)
However it's acting a bit strange in one regard. The first time I
handle (read presses from the launchpad and sends something back to
turn lights on/off) it works as expected.
However the next time I launch my chuck code (without turning off =
unplugging the launchpad) it doesn't send presses. However the arrow
up, down, left and right buttons (or at least the up-one, that's
what I got used to use) works and after pressing it the other
buttons start sending again.
Every once in a while, it's the other way around, I have to press a
grid button before the arrow pads start sending.
I checked my chuck code quite thoroughly, and played with various
things to remedy the problem, but still it might be something I send
that messes up the launchpad.
Can anyone recognize this behavior? Or the opposite: testify that it
works without this quirk? Any ideas how to approach the problem,
narrow down the possibilities and hopefully eventually find a fix?
That is because the LP sends MIDI using running status, and there
is no way to reset it (i.e. force a status byte on the next message),
except a power cycle. The top row uses controller events while the
rest uses key up/down. After re-opening the device the driver code
needs a status byte, and usually using the top row will provide one
(assuming the last event in the previous session was a key one).
Actually *most* events are unambiguous even without a status byte,
but you'd need some ad-hoc code in the driver to exploit that.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)