3.4.0: Added support for the ancient Launchpad MK1

[niekvb]

Hi, thanks for developing and providing this package!

I added support for the prehistoric legacy Launchpad. It has some limitations as expected (which are described in the README) but it should work fine with the API you set out.

Changes made shouldn't affect the API that was already in place, except for one:
I added a TS generic argument to autoDetect() to be able to easily modify the expected return type of the method in case you already know the type of Launchpad that is returned.

Example usage:

const mk1: LaunchpadMK1 = autoDetect();
const mk2 = autoDetect<LaunchpadMK2>();

This should be fully backwards compatible though as it will return ILaunchpad by default.

It might have been better to actually restrict the kind of result that is returned by autoDetect() in order to properly detect the right Launchpad instance to return but I think in most cases the generic argument should be sufficient.

Additionally, for MK1 I added LaunchpadMK1.BUTTONS (of new type ButtonLayout) to easily iterate through available buttons which might be useful for newer models too.

I tested these changes for MK1 only as I don't have access to other models. Please let me know if you need anything :)

[duncte123]

Thank you! I was unable to find a second hand mk1 myself hence I was unable to add it

[niekvb]

Thank you! I was unable to find a second hand mk1 myself hence I was unable to add it

My pleasure! Don't buy one though hehe, mine unfortunately hasn't held up quite that well over the past 13 years with some half working buttons and flickering LEDs.

[niekvb]

Another note: I incorrectly assumed RGB values for other LP models were in range 0..255. That was before I discovered the PR for adding MK3 support which mentions changing to range 0..1 and internally scale this value to the ranges accepted by LP models.

I didn't implement this behavior yet (MK1 only supports 0..3) and I'm unsure if it is desirable to scale 0..1 to an integer in range 0..3. Implementing scaling would enable the same way of setting LED colors like with newer models, but it is still missing a blue LED and can only display about 16 colors and therefore isn't really compatible with newer models.

Scaling would allow continuity along newer models but it could also mask the limitations of MK1... I'm curious about your view on this.

EDIT: On second thought, I will add scaling because it does make it a lot easier in case you need to switch between models and improve the docs a little about the limitations. (:

[duncte123]

Keeping the API consistent indeed sounds like the best solution here

[niekvb]

Limitations for MK1:

• setButtonColor() same parameters except it can't consume a PaletteColor (number) but will accept a Velocity (number) value instead.
• flash() and pulse() accept a Velocity instead of PaletteColor, and additionally accept RG(B) tuples. (It's a shame newer models don't seem to accept custom colors for flashing and pulsing otherwise these methods could be more compatible)
• setButtons() accepts different styles that use parameters mentioned above.

Result: MK1 is "backwards compatible", replacing a MK1+ device with MK1 won't cause compilation issues, though ColorPalette values aren't compatible. Upgrading a MK1 to MK1+ requires more work as the APIs are less compatible.

I think this is the most compatibility we can reasonably get :)