I’m working on a controller interface for my LaunchPad Pro mk3 with bidirectional feedback.
Users will see a grid of 64 buttons, they can right click a button to set the button mode (latch, hold, trigger) and the button color.
The module should know about the button’s on/off state which is easy enough to do w/ a ParamQuantity, but it should also know about the button’s color so it can send feedback to the LaunchPad Pro via midi.
The color and button mode will also need to be serialized for recall.
Hi @lempface, and welcome to the forum! Sounds like a great project.
If you want them all exposed as Params, just set up the button modes using an enum (as if they were a multi-position switch). I’m not familiar with the LaunchPad Pro API, although I’m thinking of getting one soon–are the button colors picked from a defined list, or are they all independently flexible? If it’s the latter, you may want to treat colors as a non-parameter internal array that you manually add to the serialization.
I’m pretty far along in concept and just working on doing it in-pattern. The LPPro pads respond to midi notes 11-88 and velocity chooses the color which is a color assigned to each of the possible velocity values 0-127, 0 being off.
The buttons surrounding the main grid respond to cc numbers and cc values with the same color mappings. Solid light messages are sent on channel 1, and pulsing/flashing on channels 2/3.
Rack widgets are designed to be 1:1 with a signal. I’d model these this way:
A switch param for the button. This is the down/up state of the button, which is normal for a button param. In your process you’ll detect a changed state of the param to send the appropriate midi. The Param id is an index that can be used for indexing arrays for all other data associated with that button.
The rest of the data you need is configuration for the button:
Latching (same as hold) or momentary (trigger), which is 1 bit or a bool.
MIDI assignment (note) (7bits)
MIDI Channel (1 bit)
MIDI Velocity (7 bits)
These all could be params, without any associated direct UI control, but not a huge benefit to that. the configuration data is fine kept separately, but that means writing the serialization code.
That’s 16 bits of information that you can encode in a single uint16_t. If you’re not comfortable with bit twiddling you can create a struct that has this button descriptor. The midi assignment, velocity and channel are probably most conveniently encoded as a rack::midi::Message. That way, when the button is engaged you just send that message, and you have logic to decide when to send the note off. You could have an array of these indexed by the param id of the button. For simplicity, you could track the latching configuration in a bool array, and one array of the MIDI messages.
A configuration UI could be done with just a few controls.
One (linear cursor) or two knobs (x/y) to select a pad to configure.
Perhaps a latching button for “learn” mode.
One 2-value switch param with a switch for channel 1 or 2.
One 11-88 param knob with snap enabled for MIDI note.
One 0-127 param knob with snap enabled for velocity (color).
One 2-value switch param with a switch for momentary/latching.