ok Danoise, maybe you can help me out with this one. Is there a way to change the rslt of function LaunchpadMK2:output_value() to a sysex message instead of a standard midi message? Novation allows individual setting of the RGB values through sysex and I think it would be an easy and more dynamic way of setting the color than trying to parse an 3 number RGB array to a 0-127 decimal.
I think it would be an easy and more dynamic way of setting the color than trying to parse an 3 number RGB array to a 0-127 decimal
I respectfully disagree. the color is already an array, so you’ll end up parsing it somehow, anyway.
But of course, since you are writing that driver you can do it in whichever way possible -
The Launchpad is based on MidiDevice, which in turn is based on the more generic Device class.
Here’s what the documentationhas to say about output_value():
--- Convert values into a something that the display & device can understand.
--
-- Each type of value (number, boolean or text) is handled by a specific
-- submethod: @{output_number}, @{output_boolean}, @{output_text}
--
-- Numbers are generally used for dials and faders, booleans are
-- used for objects with an on/off state (buttons), and text is used for
-- things like labels and segmented displays
--
-- Depending on the device, you might want to override these submethods with
-- your own implementation. For example, the Launchpad has its own method for
-- converting a value into a color. You can also implement your own code for
-- direct communication with the device by overriding these methods -
-- in such a case, adding an additional boolean return value ("skip_hardware")
-- will update the virtual display, but skip the hardware part
So yes, you can send raw sysex using send_sysex_message(), and then “skip hardware” as explained above
Edit. btw: you also want to change the colorspace property, for the Launchpad classic it looks like this
-- this device has a color-space with 4 degrees of red and green
self.colorspace = {4, 4, 0}
Which means, blue is ignored. You probably want to specify {4,4,4} as the new value.
Only once you have set this value can you start modding the device configurations to specify blue colors for the various applications.
Thanks for the detailed explanation. The “skip hardware” but was what I was missing.
I’m going to have to think about this. I wrote a method last night after I posted this that takes in the pt.color array and finds the closest value in a table of hex color values that correspond to the launchpad colors. Then it outputs the decimal corresponding to that color. It works just fine, I guess it just feels clunky. Is there a performance drawback to using sysex instead the 0-127 value?
I’ll post my code tonight, maybe I’ll think of a better way to do it during the day.
So for anyone interested, here is the github for the Launchpad MK2. The only map that is done is the MixerMatrix. I got all of the LEDs and buttons working properly. I will be doing the rest of the maps and fine tuning next week.
@danoise I ended up sticking with the 0-127 values for the colors. I have the sysex code in there, and it works, but the colors just didn’t turn out like I thought they would, they were a little lighter than the colors on the screen. I think the launchpad LEDs driver may interoperate the colors a little different than my monitor. So i’m going to just use the 0-127 method and fine tune it next week. Thanks for the help.
Hopefully not too much work to adopt all those controlmaps. This one thing where I thought of coding a visual editor.
In any case, regarding those colors: yes you will never see a complete consistency between onscreen and device colors. Just think of how the minimal brightness for the Launchpad is dark, almost black, on screen but of course, can’t look that way on the actual device 
LEDs often have very different strengths too, for example my Launchpad has quite weak green shades and strong yellows. For this reason, I picked colors that looked good on the device, not the screen
It shouldn’t be too hard now that I know what I’m doing.
Also, I found a function MidiDevice:extract_midi_note() in the duplex code, but it doesn’t seem to be in the framework documentation. I just wanted to let you know about that.
I made a different implementation ofLaunchpadMK2:output_value()
https://github.com/amoetodi/Renoise-Duplex-Launchpad-MK2
You’d mapped your colorspace to {1,1,1} but there are {64,64,64} available colors. Most of these can only be called through sysex messages, there are colors that can be called via MIDI messages, but Novation just picked 128 colors and put them in a mostly random order to maintain easy compatibility with Live, but mapping RGB to their weird made up colorspace is too much of a pain to be worthwhile.
I was wondering if someone could help me with a less hackish way of implementing the thing I’ve kind of got working inLaunchpadMK2:output() with rainbow_mode using the Keyboard application. Right now, output_value() passes out the expected color, but when rainbow_mode is on and the user presses a button on the LargeGrid I replace it with a color of my own. I’ve mapped the circle of fifths to the colorwheel, so when chords are played in IsomorphicLayout on the Launchpad, consonant chords have similar colors and dissonant chords clash. The way I’ve coded this means the colors are laid out in IsomorphicLayout even when the grid isn’t. I was hoping someone could help me create a more generalised version of the code. I think it’d be quite easy if I could figure out how to get the pitch that is being sent to the sound engine after it has been quantized to the scale, rather that the pitch of the midi message received from the Launchpad. If not, if it were possible to work out through code which layout has been selected, I could write a color picker for each layout, but this seems a bit inelegant and would mean more effort each time a new layout is added. In any case, I prefer the IsomorphicLayout, so I’ve got most of the functionality I wanted now, but if it could be improved that’d be even better.
I made a different implementation ofLaunchpadMK2:output_value()
https://github.com/amoetodi/Renoise-Duplex-Launchpad-MK2You’d mapped your colorspace to {1,1,1} but there are {64,64,64} available colors. Most of these can only be called through sysex messages, there are colors that can be called via MIDI messages, but Novation just picked 128 colors and put them in a mostly random order to maintain easy compatibility with Live, but mapping RGB to their weird made up colorspace is too much of a pain to be worthwhile.
I like your → magic number dance 
A shame if the full range of colors is not in formatted in a sensible way… then I better understand dplduffy’s approach.
when rainbow_mode is on and the user presses a button on the LargeGrid I replace it with a color of my own. I’ve mapped the circle of fifths to the colorwheel, so when chords are played in IsomorphicLayout on the Launchpad, consonant chords have similar colors and dissonant chords clash
Wow, really? I’m happy to see such a great improvement in the keyboard. I think I can help, too:
I think it’d be quite easy if I could figure out how to get the pitch that is being sent to the sound engine after it has been quantized to the scale, rather that the pitch of the midi message received from the Launchpad.
My xLib project has a class called xScale
-- restrict a note to a specific scale and key
function xScale.restrict_to_scale(note_value,scale_idx_or_name,scale_key)
Simply require the class in your tool and you should be good to go (it does not have any dependencies)…
I got it to work, now rainbow_mode works in every layout. I ended up casting the button text as a number and working out the color from there. I also added three different color palettes, a bright one and two more pastel shaded ones. I’ll probably tweak it a bit more, but for now I’m quite happy with it. I’ve updated the code on github for anyone who wants to try it, I’ll make a video at some point today to show the colors.
Well, that was quite a surprise noticing you guys got this thing to work. Great job!
Although I am not familiar with LUA scripting, I just downloaded the files from Github and added them to the Duplex Controllers folder. The MK2 shows up in the browser, but I get an error that class LaunchpadMK2 is ‘unknown’ (although it is there in the ‘root’ folder of the device). Most likely I forgot something, but I have absolutely no idea what it can be. Both Renoise and Duplex are updated to the latest version (Renoise 3.1 and Duplex v1).
Got it working now. My mistake was a wrong name for the folder (named it Launchpad-MK2 instead of LaunchpadMK2). 
Once again, thanks guys for getting this thing to work!
I just picked one of these up used and cheap. I’m noticing only the first Matrix+Nav+transport works. Did the other mappings get finished or should I dive in?
Can you assign samples to each of the pads and use it as a giant drumpad controller instead of as a clip launcher?
64 velocity sensitive pads each with their own samples assigned could be interesting…that is if they are sensitive enough to be played that way.
I know its primarily intended as a clip launcher…
I made a different implementation ofLaunchpadMK2:output_value()
https://github.com/amoetodi/Renoise-Duplex-Launchpad-MK2
You’d mapped your colorspace to {1,1,1} but there are {64,64,64} available colors. Most of these can only be called through sysex messages, there are colors that can be called via MIDI messages, but Novation just picked 128 colors and put them in a mostly random order to maintain easy compatibility with Live, but mapping RGB to their weird made up colorspace is too much of a pain to be worthwhile.
I was wondering if someone could help me with a less hackish way of implementing the thing I’ve kind of got working inLaunchpadMK2:output() with rainbow_mode using the Keyboard application. Right now, output_value() passes out the expected color, but when rainbow_mode is on and the user presses a button on the LargeGrid I replace it with a color of my own. I’ve mapped the circle of fifths to the colorwheel, so when chords are played in IsomorphicLayout on the Launchpad, consonant chords have similar colors and dissonant chords clash. The way I’ve coded this means the colors are laid out in IsomorphicLayout even when the grid isn’t. I was hoping someone could help me create a more generalised version of the code. I think it’d be quite easy if I could figure out how to get the pitch that is being sent to the sound engine after it has been quantized to the scale, rather that the pitch of the midi message received from the Launchpad. If not, if it were possible to work out through code which layout has been selected, I could write a color picker for each layout, but this seems a bit inelegant and would mean more effort each time a new layout is added. In any case, I prefer the IsomorphicLayout, so I’ve got most of the functionality I wanted now, but if it could be improved that’d be even better.
I’m just trying your script out, works really well so thank you very much. I am curious about the top half of pads when playing, what are the two coloured blocks representing?
@Meef Chaloin: Right, I forgot that Duplex actually had support through this. Relevant to this topic, I guess:
https://forum.renoise.com/t/is-there-anything-i-can-do-with-a-launchpad-mk2/48204
But question is, is it good enough? Because, then I’m going to include it in future versions. You tell me 
I’m just trying your script out, works really well so thank you very much. I am curious about the top half of pads when playing, what are the two coloured blocks representing?
Mmmm…are you running Duplex (Keyboard)?
There are_many_things you can do with a Launchpad. In this case, it’s a split keyboard layout (lower part and two smaller upper parts). Each one can be configured via options.
And you can always create your own layouts by modifying the configuration files…
It seems good enough to me so far but I have only started playing with it and I don’t know what other things it could potentially do. It’s certainly better than nothing! I thought I encountered a couple of bugs in it but I will need to play with it a bit more to check those.
I’ll have a look at the options regarding the upper and lower keyboard layout, I couldn’t make sense of the upper part with the default settings.
A couple of things about general duplex:
With this script every time I changed from one script/mode to another the midi I/O was set to none, is that normal?
Also, Is it supposed to be used by using the mouse to change script/mode? It would be great if there was somehow a way to change it from the controller itself but perhaps this would use up too many buttons?
With this script every time I changed from one script/mode to another the midi I/O was set to none, is that normal?
The tool saves the I/O for each configuration. So you might have to adjust them - but just once, then you’re good to go.
Also, yes, there are some mouse-free way to switch between applications.
- The application called SwitchConfiguration allow you to select “next”, “previous” configuration
SwitchConfig is suitable when you need to switch absolutely everything. But you will need to create unique configurations that make use of it.
For example, here are the Ohm64 configurations. Each one comes as a “switchified” and regular version:
- A control-map feature called States, which can switch or toggle things on your controller. A bit like pressing SHIFT or CAPS LOCK on the keyboard.
States is a newer, more flexible way to do things. You can check out the LP keyboard configuration - it uses the feature to toggle the two upper grid on/off:
But question is, is it good enough? Because, then I’m going to include it in future versions. You tell me
I’ve cleaned up the code a bit again. It should be good enough for future versions. There is a slight bug with the Keyboard configuration, when it launches it’s in DimStateA, but it’s lit up as if it’s in DimStateB. Toggling the state twice clears it, but it draws the wrong state when it’s connected, I’m not sure how to fix that. Other than that I’ve not had any problems using it.
I’ve cleaned up the code a bit again. It should be good enough for future versions.
Wow, that’s awesome. Thanks!
Will quickly check out the “dim-state” issue you mention… it most likely isn’t caused by you.
Hi Everyone,
Sorry to revive this thread, but I just started trying to get my Launchpad MK2 going with Renoise and Duplex (I am currently running Renoise 3.1). I installed the main tool, and then created a new folder under “Controllers” named LaunchpadMK2. Then, I simply copied everything from @stellartux’s Github fork into that new folder. When I try running the script (specifically trying the Keyboard tool), the grid initially lights up fine. However, I then start to get Scripting Tool errors. For example, the first line says Tools/com.renoise.Duplex.xrnx/main.lua failed in one of its notifiers. . . . LaunchpadMK2.lua 65: attempt to perform arithmetic on a nil value.
. . . Device.lua.631: in function ‘output_value’
. . . Display.lua.353: in function ‘set_parameter’
. . . Display.lua.284: in function ‘update’
. . . Display.lua.587: in function ‘_send_message’
etc.
I have not typed out all of the errors, but can certainly do so. I am hoping, though, that I missed something simple (like forgetting to add a file or line of code somewhere) that somebody who knows more than me can identify quickly.
Thanks in advance for your help!