New tool (3.3.0): Arturia KeyLab mkII v1.3 build 023 (January 2021)

Hey Raul,

thanks for your efforts writing this tool. I was looking into your source to find something which could be used for a Keylab/Minilab MK3 tool… Sadly the code structure seems to be somewhat chaotic. Did you somehow run your code thru a obfusciator or simplifying tool or something?

If not, I would highly recommend to you to read/think about “mapping”, “multidimensional objects”, like for example, you can of course use tables within tables. Instead numeric indices, you can use words. Instead putting all tooltips into a single table, you could put the tooltip into the “fader description” table instead.

You can also map functions within a table. No need for doing long if else clauses here.

Just a loose example for a better data / config structure:

faders = {
  awesomeFader1 = {
    label = "Fade away",
    toStringConverter = function () ... end,
    toNumberConverter = function () ... end,
    tooltip = "What a nice tooltip",
    mappedMidiSysex = { 0xff, 0xfe, 0x01, 0x02 }
  },
  extremePowerFader2 = {
    label = "Fade in",
    toStringConverter = function () ... end,
    toNumberConverter = function () ... end,
    tooltip = "extreme Powerfader tooltip",
    mappedMidiSysex = { 0xff, 0xfe, 0x01, 0x03 }
  },
  ...
}

Then you could simply iterate over this structure in nested loops and build it up, like so, or similar:

for faderKey, values in pairs(faders) do
  print(faderKey, values.label);
  local stringConvertedValue = values.toStringConverter(42 or whatever[faderKey])
  ...
end

Please think about this… I believe this would help you a lot with coding. And also help others who want to contribute, reuse or extend…

Also keep in mind that you also can pass a whole method to another method as parameter, which commonly is then called a “callback method”. Like so:

function renderFader(id, callbackFunction)
   ...
   local tooltipText = faders[id].tooltip
   callbackFunction(tooltipText)
end

renderFader("awesomeFader1", function (tooltipText) showTooltip(tooltipText) end)

This is just an example. I think by knowing these two patterns, you could highly improve and shrink your code, also make it more maintainable and way more human readable (for yourself, too, assuming you are human).

Thanks for consideration and greetings!

Hi ffx.

Before wasting time on other code, it is recommended to study and compare the hardware, to avoid confusion.

The Minilab MK3 has practically nothing to do with the Keylab mkII. Although they are keyboards from the same brand, they work differently. Taking old code from a tool to adapt it to other hardware only serves what you have done, trying to change the way of programming, instead of finishing a new tool for the Minilab.

I appreciate your advice on code that I programmed almost 5 years ago. Until now I have drastically changed my way of programming, since a structure for tools of more than 30,000 lines of code is necessary. And certainly, when I program, even today, I don’t expect another programmer to modify anything. Who is interested in these things in these forums? I think 4 people? There you have it.

I particularly don’t like mixing variables with functions inside tables. I prefer to put variables and functions together within separate tables. I also don’t usually use “for in pairs/ipairs” iterations, I prefer “for do”. And well, calling a function from another function is fine if the called function is used in a multitude of functions.

I use strategic tags a lot in the names of functions and variables. With the search engine, there is nothing faster than that when you have a lot of code.

Thank you for your comments. I assume you have a Minilab mk3 tool on the way.

And well, yes, I’m still a human being :grinning:.

By the way, I haven’t had the Keylab MkII for about 2 years. I bought this keyboard second-hand and resold it. I liked the experience, to a certain extent. Ultimately, I settled on an 88-key keyboard with fewer knobs for composing. Sometimes, less is more.

Ah, I see. Didn’t realize this tool is already this old :blink: I just wanted to get a clue about the effort doing an general MCU (+ special modes for arturia) tool… I currently only have a Minilab 3 and a Behringer Motor 49 thing… Did you manage to display custom text on the display of the Keylab?

Maybe the faderport tool would be somehow a good starting point… Also I am not sure yet if I keep minilab 3. The recent integration in Ableton and Bitwig certainly is one of the best, if not the best, yet still buggy. Also I wonder why integration still is on such a low level.

Hi Raul,

I need your help with the midi feedback implementation. I made my own app but I am not able to control the lights of the controller from the software.
If you could help me please understanding the basics, thanks.

Hi @alfaholic, how are you?

For a start

  • If you ask Arturia for detailed information about the internal workings (receiving messages), they won’t give it to you.
  • You need to know how to send SysEx messages from your Lua tool.
  • You need to know which SysEx messages are valid for your MIDI controller! Many MIDI controllers are not supported, and some are partially supported by SysEx…
  • Understand the structure and order of SysEx messages well. Each number means “something”.
  • You can make the LEDs turn on or off if the MIDI controller has those SysEx messages associated with it.
  • With RGB LEDs you can change color, turn on or off. If they are not RGB, just turn on and off.
  • Trial and error. If you know some SysEx messages, you can use similar ones to experiment. You can figure out more on your own.
  • It is also possible to change the state of the screen or send “words” and such. However, screens like the ones on these Arturia keyboards seem absurd to me. They are very small, from the '90s. MIDI controllers are too expensive to incorporate such a crappy screen.

What MIDI controller are you trying to control?

Extra info for programming

For sending messages, please read all the related information from the Renoise documentation about:
renoise.Midi.create_output_device()

Example from some of the code related I programmed a long time ago.:

local AKM_MIDI_DEVICE_OUT=nil
local function akm_output_midi(out_device_name)
  if not table.is_empty(AKM_OUTPUTS) then
    if not out_device_name then
      return
    else
      AKM_MIDI_DEVICE_OUT=renoise.Midi.create_output_device(out_device_name)
    end 
  end
end


local function akm_output_midi_invoke(tbl)
  if (AKM_MIDI_DEVICE_OUT and AKM_MIDI_DEVICE_OUT.is_open) then
    --local message={0x90,0x5E,0x7F}--{0xF0,0x00,0x20,0x6B,0x7F,0x42,0x02,0x00,0x10,0x6D,0x7F,0xF7}
    AKM_MIDI_DEVICE_OUT:send(tbl[1]) --{tbl[1],tbl[2],tbl[3]} --send(message)
    print(("%X %X %X | %s"):format(tbl[1][1],tbl[1][2],tbl[1][3],AKM_MIDI_DEVICE_OUT.name))
  end
end

Here is an example of SysEx tables (the first subtable) to change the state of LEDs. I added the string to associate it with each table. You can program your messaging tables as you prefer:

  {{0x90,0x08,0x7F}, "solo_sel1_on"},
  {{0x90,0x08,0x00}, "solo_sel1_off"},
  if (rule=="left_button_on") then AKM_MIDI_DEVICE_OUT:send {0xF0,0x00,0x20,0x6B,0x7F,0x42,0x02,0x00,0x10,0x1A,0x7F,0xF7} vws.AKM_BTT_LEFT.color=AKM_CLR.MARKER return akm_left_button_repeat() end
  if (rule=="left_button_off") then AKM_MIDI_DEVICE_OUT:send {0xF0,0x00,0x20,0x6B,0x7F,0x42,0x02,0x00,0x10,0x1A,0x07,0xF7} vws.AKM_BTT_LEFT.color=AKM_CLR.DEFAULT return akm_left_button_repeat(true) end

  if (rule=="right_button_on") then AKM_MIDI_DEVICE_OUT:send {0xF0,0x00,0x20,0x6B,0x7F,0x42,0x02,0x00,0x10,0x1B,0x7F,0xF7} vws.AKM_BTT_RIGHT.color=AKM_CLR.MARKER return akm_right_button_repeat() end
  if (rule=="right_button_off") then AKM_MIDI_DEVICE_OUT:send {0xF0,0x00,0x20,0x6B,0x7F,0x42,0x02,0x00,0x10,0x1B,0x07,0xF7} vws.AKM_BTT_RIGHT.color=AKM_CLR.DEFAULT return akm_right_button_repeat(true) end

General thought. Most MIDI controllers on the market have been designed for years “to sell”, not to fully satisfy the user. It’s a business. Don’t expect great things with the code implementation. That’s why you continually see MK2, MK3 models, with hardly any evolutions. Many times it’s all about image. That’s why SysEx compatibility and other implementations are incomplete in many controllers, and are private to the brands. They are not interested in people knowing how they are made. You can find SysEx compatible MIDI controllers that don’t allow you to change the RGB colors of the pads from SysEx, for example. It’s absurd! That’s the thing!

1 Like

Thanks Raul.

I have Keylab 61 MK2, and want to use it with Giglad, which is a software arranger, just Like Yamaha, Korg, or Roland.

I need to control the LED state (On, Off, Flash), and nothing else as this is important for the arranger to send back to the controller.

When using the Keylab 61 MK2 with Reaper over HUI protocol it receives the midi feedback so Reaper actually tells the controller which LED to turn on and off. Without Reaper connected over HUI the controller does not turn the buttons ON.
When using it in USER mode this does not work, the buttons colours, and LED state is actually static, set by the user in the settings for every button.

So I have 3 questions:

  1. Should I implement a small part of the HUI protocol in Giglad to be able to control the LEDs, or it can be done with the generic midi and SysEx messages?

  2. Is Keylab capable of receiving the LED state feedback in USER mode or just in DAW by using HUI?

  3. Any way of making this LED feedback only universal for other controllers brands and types?

I guess each keyboard mode accepts or does not accept message input. In the particular case of the Keylab mkII controller, I used the MCU mode to send SysEx messages. I think in other modes it doesn’t work (or yes). That depends on the firmware and what the brand allows.

There is no way to standardize a single SysEx configuration for all MIDI controllers on the market. Each MIDI controller has a particular use with SysEx. It depends on how they implement it in the firmware and the peculiarities of the MIDI controller itself.

In fact, each complex SysEx message (the longest one) has a unique number at the beginning that is only valid for a specific brand (it is designed that way). For Arturia I think it is “0xF0”.

Here is some related information I just found:

In short, if you want to control 20 MIDI controllers with SysEx, you need to have 20 different codes programmed.

Another thing is to use another mode of the MIDI controller that uses another kind of more standardized messaging for basic things like transport buttons, for example, things that may work on other MIDI controllers that use the same messaging implementation… Maybe this other messaging is closed, you can’t reprogram it. But with SysEx you can customize it according to the compatibility of your MIDI controller.

Find out what kind of messaging each particular mode uses on your MIDI controller.

I don’t know Giglad. All I know is that the messaging information has to be programmed somewhere and it has to be compatible for each particular MIDI controller if it is SysEx. In the case of Renoise, Lua tools can be programmed to SysEx. In Reaper, that messaging information has to be programmed somewhere in the DAW. So on for all of them.

Thanks Raul, I just tested it and it works in both modes, DAW and USER.

Please correct me if I did not understand this correctly:

The button on the controller sends the simple NOTE or CC to the host software, but it is the host software that sends back the appropriate SysEx message to control the LED behaviour.
Is this the reason why I do not see the SysEx messages when monitoring the midi going out from the controller.
Correct?

If this is the case, what is the procedure find out about which hex data the controller receives, how to monitor the returning midi if I want to see for other brands and models?

Hi @alfaholic Sorry for replying so late! I’ve been a bit busy lately.

MIDI messaging is bi-directional. Every DAW should have some way of displaying this messaging. Here’s a quick example in Renoise.

Go to the Renoise MIDI tab. There are 2 panels here:

  • MIDI In: This is the MIDI messaging that the software (Renoise) sends to the MIDI hardware controller.
  • MIDI Out: This is the messaging that the MIDI hardware controller sends to the software (Renoise).

Yes, here you can see the typical CC messages and SysEx messaging, and they should not be confused.

It may happen that you send a message (on MIDI In) and the MIDI hardware controller does not react, because it does not support this message. The firmware of the MIDI hardware controller must be prepared.

It is common for MIDI controllers to have several configurable connections to receive (MIDI In) or return (MIDI Out) messages, so you can use 2 programs to interact with the MIDI controller, a DAW for example and another software program, for example, the software program that usually comes with the USB MIDI controller.