On Fri, Jul 13, 2012 at 08:50:18AM +0200, Atte André Jensen wrote: That seems to apply only to messages sent *to* the LP: it wants a status byte in each one. But doesn't do the same in the LP-> app direction. I also tried the reset command, but it too does not clear the running status. AFAIK only a power cycle will. You'd have to switch the power on the USB socket... It's not the USB drivers failing to reset, but the LP firware. It is possible if you have LP-specific driver code. Only two keys are ambiguous without a status byte: both have 0x68 as the first data byte (the second is press/release, encoded the same way in all cases). For all others you can infer the status byte form the data. When I got my LP I wrote a python extension and class that uses it directly via libusb, without going via ALSA, and it solves the problem, except if the first event has data byte 0x68. This is part of the code, with _cstat being the current status, initialised to 0, and p is an array of n received bytes: i = 0; while (i < n) { t = p [i++]; if (t & 0x80) // First byte is status ? { _cstat = t & 0xF0; t = p [i++]; } v = p [i++] ? 1 : 0; // If we don't have status, find it from the data. if (! _cstat && (t != 0x68)) { _cstat = ((t & 0x0F) > 8) ? 0xB0 : 0x90; } // Keys are encoded with x,y = 0...8. // x == 8 means the right column. // y == 8 means the top row. if (_cstat == 0x90) rx_action (v, t & 0x0F, t >> 4); if (_cstat == 0xB0) rx_action (v, t & 0x07, 8); }. 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)

Or, more accurately, either one of them not working depending on what message was sent before the new connection was made.

Yeah, the same for me. I was referring to these keys in the context of Fons' solution which could be implemented in a driver. The problem is basically that the LP doesn't send full midi messages but only the type (CC or NoteOn/Off) for the first message and then just messages without the type specified for any subsequent message. If you switch application in between then the program won't know what type of message you are talking about anymore. You can test this out by pressing on of the buttons that sends a CC (top row) and then immediately restarting your application. Now the top row won't work until you hit one of the grid buttons. As for a more immediate solution. Have you tried sending the LP two remap messages (i.e. CC 0 2, CC 0 1) before quitting?

On Fri, Jul 13, 2012 at 07:58:31PM +0100, Kaspar Bumke wrote: No, key release is velocity 0. 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)

I think it was driven by cost reduction mainly. It was pretty much all they could manage with the low cost MCU they used. You can see all the details in this teardown.<http://www.illuminatedsounds.com/?p=583>Look at the comments too for some insights from one of Novation's engineers.

On Fri, Jul 13, 2012 at 05:41:31PM +0100, Kaspar Bumke wrote: Didn't try that. The python interface doesn't support remapping, because its output is not midi, just v,x,y, and any remapping can be done as well by the application. I did try the reset command, it doesn't clear running status. One solution probably (not tried) is to use the LP via Jack MIDI, that way the device remains open as long as Jack is running, and running status is preserved, even while there is no client using the LP. 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)