ReaKontrol: Komplete Kontrol Mk2 deep integration with Reaper

[Mark90]

Hi,

Have got Cubase Pro on Mac and using Midi monitor I have attached a list of all the SysEX that Cubase sends to the MK1 S88 to unlock the buttons. (see SysEX.txt)

When unlocked..
The Keyboard spits out the following CC’s on channel 16
UP arrow cc16 Value 1
Down arrow cc16 Value 127

Encoder clockwise (Navigate knob) CC28 value 127
Encoder counter clockwise CC27 Value 127

Loop CC20 value 127
Cubase sends;
11:27:14.064 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 06 00 7F 00 00 00 F7 (To turn Loop light on)
11:27:14.064 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 06 00 00 00 00 00 F7 (Light Off)

RWD CC 21 Value 127
Cubase sends;
11:28:31.993 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 07 00 7F 00 00 00 F7 (light on)
11:28:31.993 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 07 00 00 00 00 00 F7 (Light off)

FWD CC22 Value 127
Cubase sends;
11:34:23.417 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 08 00 7F 00 00 00 F7
11:34:23.417 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 07 00 00 00 00 00 F7

PLAY CC 17 value 127 to turn on illuminate button. (TOGGLED BUTTON)
Cubase sends;
11:36:19.410 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 03 00 7F 00 00 00 F7
11:36:19.605 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 05 00 00 00 00 00 F7

PLAY CC 23 value 127 to turn off. (TOGGLED BUTTON)
Cubase sends;
11:36:19.410 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 03 00 7F 00 00 00 F7
11:36:19.605 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 05 00 00 00 00 00 F7

REC CC18 Value 127
Cubase sends;
11:40:19.918 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 04 00 00 00 00 00 F7

STOP CC19 127 when pressed

Cubase sends when play is on
11:41:53.477 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 05 00 7F 00 00 00 F7
11:41:53.477 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 03 00 00 00 00 00 F7

Cubase Sends When Rec is on
11:43:05.705 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 05 00 7F 00 00 00 F7 (switch on play light)
11:43:05.717 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 03 00 00 00 00 00 F7 (Switch off play light)
11:43:05.717 To Komplete Kontrol DAW - 1 SysEx Native Instruments 15 bytes F0 00 21 09 63 75 62 61 04 00 00 00 00 00 F7 (Switch off Rec light)

Shift and left arrow CC25 127 (Undo)
Shift and Right Arrow CC26 127 (redo)
Loop and main encoder clockwise (Move cycle right) CC30 127
Loop and main Encoder counter clockwise CC29 127

Shift and stop to toggle the metronome the keyboard sends
CC24 127
CC19 127
CC24 127
And then cubase sends loads of SysEX

Shift and Rec (Toggles the count in)
CC24 127
CC18 127
CC24 127
And again Cubase sends loads of SysEX

Hope this proves useful in using the MK1 keyboards with Reaper

[DrFrankencopter]

Thanks @Mark90, I tried sending the same Sysex to my S-61 and had no joy in getting any MIDI output from the nav buttons and encoder.

It does, however make the stop button light up and then go out...

[terminar]

@_Stevie_ be carefull with the USB connection.

This is (in all cases i know) handled by NIHIA or NIHA which then provide some functionality to the DAWs (via virtual Midi port). If you try to use the plain USB connection that's possible but then you have to get exclusive access (which means you have to kill NIHIA or NIHA, depends on device). Then, nothing is working anymore like KompleteKontrol or Machine2 or whatever.
That applies to the KKMK2/KKA/KKM but i think it's the same situation with the MK1.

KompleteKontrol and the other SW stuff like Machine2 use their own NIProtocol, that has nothing to do with USB. The NI-SW talks directly to the Agents/Services (NIHIA/NIHA) via NamedPipes (on windows) and via Mach Ports (on OSX), this is completely proprietary and the stuff i am currently tinkering with. But it's another level as the Midi/MCU stuff.

[_Stevie_]

Thanks terminar, I hoped for that info. Because messing with the USB is not really something I would like to do, lol.

@Mark90, thanks for diving into making that extensive list!

[DrFrankencopter]

Hey @_stevie_ I was thinking that maybe the reason why the S-61 didn't really respond to the systex stream that Mark90 posted was that it was generated for a S-88. I might be grasping at straws here, but it seems that's all I can find around.

I've attached the list as just Midi Hex (without the descriptions), right up to the line where Mark90 indicates that the keyboard comes alive.

If you have MidiOx you can connect to Kontrol DAW 1 (in/out) and then open the sysex view, and under the Command Window tab you can "load file". Load the text file, and then under Command Window select "Send Sysex". See what happens...Ideally it will start responding to the nav controls.

For me I see it light up the stop light, but maybe you'll have more success since your board is the same model as Mark90's.

[_Stevie_]

Awesome, thanks @Dr. Will do tomorrow and report back. Hopefully with good news.

[Mark90]

Hi All,
Just booted up my windows installation and tried @DrFrankencopters SysEX file with midiox.
Sadly nothing happened, I have a feeling Cubase is speaking directly to the keyboard through a library as @terminar mentioned and then sending the SysEX to setup the connection.

I don't think you can start the keyboard using just sysEX messages.
Its so annoying that NI have a closed policy on the code as the keyboards would be so much more useful if they would share it.

Sorry

[terminar]

Originally Posted by Mark90

Hi All,
Just booted up my windows installation and tried @DrFrankencopters SysEX file with midiox.
Sadly nothing happened, I have a feeling Cubase is speaking directly to the keyboard through a library as @terminar mentioned and then sending the SysEX to setup the connection.

That may be true - but not directly - only via NIHIA. I took a short look at NIHIA which is in charge for the KK keyboards. There are some " NI::dawcontrol::cubase:CubaseClient,CubaseServer ,pages,...) namespaces/classes and cubase specific stuff - a lot of them. The same applies to "NI::dawcontrol:logic,live)". I can't imagine that there is a special interface for these daws but looking at the binaries it's plausible.

[_Stevie_]

Hey guys,

so I tried the method with the SysEx and I also didn't get any feedback on the S-88.

BUT, I tried to send MIDI notes. For example I sent a D6 and this will turn on the loop button. A note on with velocity 127 will turn the LED on and a note off with 0 will turn it off.
Same for the button itself, I enabled the "Komplete Kontrol DAW - 1" and pushed the buttons on the S-88. Tried only the transport buttons, but they all send simple note on and off commands.

@terminar: Interesting, but given the fact, that Live only communicates via that python file, I think there must be a way to that via MIDI.

[_Stevie_]

This is how it works,
first note will turn on the loop-LED, second note will turn it off.




To sum up:

The transport section on the left of the S-88 reacts on "Komplete Kontrol DAW - 1".
The other sections don't send anything at all, not even over the other MIDI ports.

EDIT: and I really think that the MK1 is being set into a special mode when talking in SysEx.

[_Stevie_]

More findings:

the Sysex code that Mark90 posted works when Cubase is running. I sent the same messages via MIDI-OX and the S-88 was changing the LED status.

I converted the HEX to ASCII:
F0 00 21 09 63 75 62 61 06 00 7F 00 00 00 F7 (Loop LED on)
gives in ASCII:
ð! cuba÷

I think you know what this means. These commands are specifically hardcoded to Cubase. I guess we would see a similar result with Ableton and Logic.

Not sure if this info is relevant, because I think it was in conjunction with the MK2:

Originally Posted by moss

BTW it is currently impossible to support the instance control since the necessary information is only sent to Ableton and Cubase (they check for the DAW name!).

Based on that fact I closed the real Cubase and tried to fake a Cubase9.exe process (by renaming a programm to Cubase9.exe), but this wasn't enough to make the SysEx work. So I guess we really need the key to open this door.

The magic key for the entrance must be in the python code.

EDIT: another thought: maybe the Ableton Live scripts don't work because a Live.exe is not found as a running process?

@DrFrankencopter: could you sent me that complied ReaKontrol with MK1 support?

[terminar]

Originally Posted by _Stevie_

@terminar: Interesting, but given the fact, that Live only communicates via that python file, I think there must be a way to that via MIDI.

It has to be. It's mentioned everywhere that's just working with MIDI+MCU.
Maybe the dawcontrol stuff is - again - a deeper "special" integration. I'll maybe get into that when we are finished with the NIProtocol stuff.

[DrFrankencopter]

I notice in the live Py scripts that there is a method that sends a TCP packet containing 'Hello, world' to localhost on port 60090. I don't see it called anywhere, but maybe this sends a message to the NIHIA that deep control is being requested.

I can try and whip something up to test this.

@_stevie_ I can send you the dll, but as it currently stands it does't even do as much as the MCU support that Reaper already offers (which you can enable by telling reaper that Komplete Kontrol DAW-1 is a MCU device in the Control surface preferences page).

But, if we start figuring out how to light up more buttons I can at least modify the code to make the transport lights behave properly. It's a start.

Also, not sure how best to get the dll to you. Maybe I can zip it and attach it to a post here...

[brummbear]

Looks like we get the reverse engineering juices flowing here ;-)

I won't have time to contribute to the Mk1 part but maybe this is of help for you in finding the key:

NIHIA offers 3 avenues to communicate with the keyboard:

1. IPC: This is solely meant for other NI SW such as Maschine-SW and KK-SW. Should be irrelevant for DAW integration: it definitely is irrelevant for Mk2 and is most likely also not "abused" in Cubase/Ableton DAW integration trickery for the Mk1. There is a slim chance however, that for Mk1 integration NI built a trick into KK-VSTi itself: If KK-VSTi noticed it is hosted in Cubase or Ableton it could theoretically notify NIHIA via IPC about that fact. I doubt it however as it would be a very ugly SW architecture.

2. OSC: NIHIA still has OSC ports. Originally those were used for all aspects of DAW integration before the special MIDI protocol was introduced. The OSC ports are still there and maybe only used by Cubase and Ableton to switch into DAW integration mode (and maybe for instance focus). I.e. while OSC is not necessary anymore maybe some leftovers are still in use.

3. MIDI: NIHIA supports a variety of MIDI protocols via the "DAW" MIDI port. All MIDI protocols use a combination of SysEx and CC commands. In its current version the standard protocol when you connect the keyboard is MCU, aka "Mackie".

a) The SysEx header for Mackie always starts with
F0 00 00 66 14 (00 00 66 is the manufacturer id of Mackie)

b) The SysEx header for NI's proprietary protocols start with
F0 00 21 09 (00 21 09 is the manufacturer id of Native Instruments)

b1) For the Mk1 with Cubase the header is: F0 00 21 09 63 75 62 61 (63 75 62 61 = "cuba")


b2) For the Mk2 the header is: F0 00 21 09 00 00 44 43 01 00

Headers are followed by keyboard specific commands, separator symbols and the SysEx delimiter F7. I figure that it is possible for the Mk1 to get instance auto focus via SysEx too, using the SysEx header followed by the string "Komplete Kontrol VST" and KK instance number. Maybe you can spoof traces of it when switching tracks in Cubase or Ableton?

EDIT: Also try the following: Spoof for F0 7E 00 06 01 F7 being sent to the DAW Midi port at the beginning. This "device inquiry" command has been used by NI in the past to start OSC mode in NIHIA. It seems to be popular among NI, Novation, Akai to initially configure the mode that a device (or in case of NI the intermediate device driver) will operate in.

[DrFrankencopter]

I didn't have any joy when sending the Mk1 header to my S-61. Basically what I'm looking for is any kind of 'signs of life' from the nav buttons and wheel.

Interestingly, if I launch Komplete Kontrol standalone and snoop the midi with MidiOx I can only see messages for the REC button. This is probably because it has no function in KK standalone and gets passed on on through the midi. Pressing play/stop does not show me any messages in MidiOx.

[brummbear]

Originally Posted by DrFrankencopter

Interestingly, if I launch Komplete Kontrol standalone and snoop the midi with MidiOx I can only see messages for the REC button. This is probably because it has no function in KK standalone and gets passed on on through the midi. Pressing play/stop does not show me any messages in MidiOx.

That is to be expected. KK standalone and KK VSTi/AU have no need for the DAW MIDI channel: they use IPC to talk via NIHIA with the keyboard.

In order to reverse engineer what is needed for DAW integration of Mk1 you have to snoop what is going on between a supported DAW and NIHIA, i.e. Cubase or Ableton. Just what Mark90 did. The challenge lies in snooping MIDI traffic on the virtual port locally on your system while the DAW is running and communicating over this very port. I don't know if MIDIOX is capable of doing that. MIDIOX comes into play again once you have figured out the basics and you are able to fake a session, i.e. sending SysEx to it and monitoring response plus messages from button presses.

In your test I imagine KK stand alone "claims" PLAY etc via IPC and the only thing you see on DAW MIDI is the unclaimed remainder of the MCU protocol, i.e. the MCU message of the REC button.

[DrFrankencopter]

Yeah, this is what I figured was going on. I took a look at Driven By Mossas well as the py project to drive the light guide by synthesia and it seems that both of these send midi messages as raw data on the USB HID device. I dunno, but maybe this is the key...

This is certainly out of my area of expertise (if I even have one).

[DrFrankencopter]

Ok, so I've managed to get DrivenByMoss to work with Reaper and can see that it is allowing track focus to work. It's driving the LCD of my S61. I've got MidiOx running at the same time and all I can see on it's meters is evidence of the transport buttons being pressed.

If I had to guess, I'd say that all the advanced functionality is being passed to (and from) the S61 in raw USB messages, and only the transport data shows up on the MIDI DAW-1 virtual device.

[brummbear]

Yup, for the Mk1 DBM went the hardcore USB way - I think Jürgen finally gave up on the mixed OSC/MIDI crap required for the Mk1 to work through NIHIA (although he had it running a long time ago).

I have no intentions to go the direct USB way as I want ReaKontrol to be non-intrusive and keep the rest of the NI ecosystem which I am running unaffected. It certainly is possible to support Mk1 via NIHIA because it is the way that NI does it but it seems really messy if you only look at the installation instructions they provide... OSC is still part of the game for the Mk1 from what I can see. Cubase has some built in special support. What a mess! Owners of a Mk2 or A or M series keyboard are in luck as things are much cleaner.

[DrFrankencopter]

Okay, that's interesting....I wonder if I can get a demo license of Ableton to investigate. I don't plan on buying anything to support this dev, as my main focus is Reaper.

Worst case scenario, there may be a path for some extended functionality through the USB messages. But I agree; there must be a better way! Of course, that said, personally, I don't run any parallel processes when working in Reaper, so it would work for me.

If I read you correct, there is some Early version of DrivenByMoss that had some limited functionality working via direct midi messages? If so, that's interesting...

[_Stevie_]

@DrFrankencopter: ah okay, then the dll might not be as useful right now
Concerning the OSC: I think I saw an OSC command in one of the py scripts. It was in the folder-
_NativeInstruments and not in the MK1 folder. Maybe the init process for deep integration is something
all hardware devices have in common? That’s why it is in the -NativeInstruments folder. Have to check again.
I wonder if there is an OSC sniffer?

@brummbear: very good info, thanks!
I don’t think Cubase is using IPC, because deep mode is instantiated even if the KK plugin hasn’t been loaded, yet. In the very moment you enable the MIDI ports in the S88 dll, the Sysex data that Mark90 collected is recognized, when I send it over MIDI-Ox.

The early version of DBM could indeed be a clue.

[_Stevie_]

OSC sniffer, yes there is: https://www.kasperkamperman.com/blog...c-datamonitor/

[brummbear]

DBM history as I see it:

1. Mk1 support started with USB (I guess inspired by some other folks who had figured out a way to take control of LEDs and even the display, see NI forum)

2. Mk2 started with OSC (emulating what NI did at the time for both Mk1 and Mk2 with Ableton)

3. The attempt to migrate Mk2 support also to USB (I think because Jürgen wanted to also own the displays) did not work well and was abandoned

4. Mk2 was migrated to NI MIDI protocol (just what ReaKontrol is using too)

If you look at the NI Ableton scripts for Mk1 they are a mix of both OSC and MIDI SysEx => those together with an older DBM version resembling state 2 from above could be a good starting point if you want to look at "paper" rather than monitoring traffic from a supported DAW. Cubase seems to have support built inside, i.e. it must know something about the protocol itself.

[DrFrankencopter]

I can't even get this damn thing (S61) to work with Ableton...and that's a supported DAW. I'm shaking my fist in the air and shouting "curse you Native Intruments".

@_stevie_ what's the reason you don't use DrivenByMoss for your Mk1? Maybe hardcore USB is the only sure fire way to get it to work. I gather in DBM there are a few layers to work through, cuz its cross platform and multi-application. But if we were to pull out the Mk1 stuff only and have it just talk to Reaper is that enough to declare success? This might prevent other applications from accessing the keyboard at the same time...

How much overhead is there in the DBM plugin? Just not sure if this is worth the effort...

[_Stevie_]

Originally Posted by DrFrankencopter

@_stevie_ what's the reason you don't use DrivenByMoss for your Mk1? Maybe hardcore USB is the only sure fire way to get it to work.

I'm not a huge fan of JAVA, it's just a big resource hog that I don't want to run on my DAW. And 2nd: not sure why, but the displays on my S88 flicker a lot, when using DBM. As if they would need to be redrawn.

[DrFrankencopter]

Originally Posted by _Stevie_

I'm not a huge fan of JAVA, it's just a big resource hog that I don't want to run on my DAW. And 2nd: not sure why, but the displays on my S88 flicker a lot, when using DBM. As if they would need to be redrawn.

Ha, that's fair...I'm not a java fan either. That said, I don't like C++ either (yeah, I'm an old school C coder...real-time stuff). I noticed that the transport lights seemed dim on my S61 when running DBM.

I guess what I'm getting at, is if there were a C++/C Mk1/Reaper only version would that be of interest? Just thinking it might be easier to port what's already written rather than reverse engineering the secret handshake.

Cheers!

[_Stevie_]

Yes a C version would definiely be of interest! In parallel, I'll try to monitor the OSC stream, just to see if we can find anything.
I have the feeling we are very close... Might also install Live to see how far I can get.

[DrFrankencopter]

Cool! Don't give up the fight! And share what you learn. I wish I could get the support working in Ableton, but it really feels like an alien environment to me.

And I can't shake the feeling that there is something secret happening behind the scenes...something that the SDK would have documented. Why the hell can't NI be more open with their implementation?

[DrFrankencopter]

I just found this quote on NI's site regarding the MK1 and host integration with multiple programs running:

"Using Multiple Hosts with KOMPLETE KONTROL MK1 at the Same Time
You cannot run two supported hosts with advanced integration at the same time. Running one supported host and one unsupported host at the same time is possible, however, the track selection buttons on the hardware will always shift the focus to the supported host and its plug-in instances. For hardware control of KOMPLETE KONTROL MK1 in the unsupported host, you have to manually bring the plug-in instance into focus using the computer mouse and keyboard. Note that the INSTANCE button and on-screen display are not available when a supported host is running on the system."

Seems to suggest that all the deep integration for the Mk1 only happens via direct USB messages, and not over the public MIDI port.

[brummbear]

Originally Posted by DrFrankencopter

Seems to suggest that all the deep integration for the Mk1 only happens via direct USB messages, and not over the public MIDI port.

No, that is not the case. It runs via NIHIA. NIHIA manages the exclusivity.

Check out the script "FocusControl.py" in the Mk1 folder of NI's Ableton Host Integration scripts. You can clearly see that it calls Ableton's _send_midi function to send MIDI CC and MIDI SysEx. Ableton is configured to send those messages to the keyboard's DAW MIDI port. And you can also see that the logical structure reflects what Mark90 captured from Cubase: compare how the button lights are switched on/off. Just like in Mark90's capture...


This Python script even discloses the SysEx required for automatic instance focus (line 465):

def update_status_midi(self, index, track, instrument, value):
#debug_out("UPDATE_STATUS(): track: "+track.name+" instr: "+str(instrument)+" value: "+str(value))
msgsysex = [240, 0, 0, 102, 20, 18, 0]
tr_name = track.name
for c in tr_name:
msgsysex.append(ord(c))
msgsysex.append(25)
ind_str = str(index)
for c in ind_str:
msgsysex.append(ord(c))
if instrument != None:
msgsysex.append(25)
for c in instrument[0]:
msgsysex.append(ord(c))
if instrument[1] != None:
msgsysex.append(25)
for c in instrument[1]:
msgsysex.append(ord(c))
#msgsysex.append(25)
#msgsysex.append(value)
msgsysex.append(247)
self._send_midi(tuple(msgsysex))

Happens to be exactly what James Teh implemented in his early attempts (not sure about the last separator commented out) - LOL! I think he got it right, he only failed to get the keyboard into the correct communication mode.

[DrFrankencopter]

Originally Posted by brummbear

Happens to be exactly what James Teh implemented in his early attempts (not sure about the last separator commented out) - LOL! I think he got it right, he only failed to get the keyboard into the correct communication mode.

I fear the issue may be that nobody knows how to get the the keyboard into that mode! It's a bit like there's a secret handshake that happens, something like "Hello...I'ld like advanced integration mode; let's continue this conversation over MIDI". It seems that the secret handshake for the MK2 happens over the MIDI port itself with a CC message. But I don't see any evidence of that being the case for Mk1.

Clearly Cubase does the same sort of thing...but we can't figure out what the handshake is!

[brummbear]

SysEx specifically for Cubase? Had a peek w Hex Editor in NIHIA:

Dump 63 75 62 61 F0 00 21 09

=> F0 00 21 09 63 75 62 61 (00 21 09 = manuf. ID of Native Instruments, 63 75 62 61 = "cuba")


LOL!

(should spend less time with this stuff...)

[_Stevie_]

Originally Posted by _Stevie_

I converted the HEX to ASCII:
F0 00 21 09 63 75 62 61 06 00 7F 00 00 00 F7 (Loop LED on)
gives in ASCII:
ð! cuba÷

So, if this is the command for turning on loop, maybe going into Cubase deep mode is similar. However, I would prefer Live mode
Will dig deeper!

[DrFrankencopter]

This is frustrating....every time I think to myself, just give up for a while and switch to another project I keep getting pulled back into the snooping around the Mk1 integration.

This morning I installed a python decompiler on my machine and took a look in the Ableton Live resources directory: ProgramData\Ableton\Live 10 Trial\Resources and I found three compiled py files with Komplete in them. The one 'komplete_kontrol_base.pyc' was the one of interest. The de-compiled code is attached as a text file.

First, note at the top that: is_s_mk2 = False

Later you'll see a handshake method.

def _send_handshake(self):
self._handshake_response_pending = True
self._handshake_control.send_value(0, force=True)

So it does seem that the handshake is 0.

There is also a receive method that I presume tells Ableton that the keyboard is connected and that it should update the methods/functions available.

@listens(u'value')
def _on_handshake_response(self, _):
self._handshake_task.kill()
if self._handshake_response_pending:
self._handshake_response_pending = False
self.set_components_enabled(True)
self.refresh_state()

The handshake control instance is created at the bottom of the method _create_controls

self._handshake_control = create_button(1, u'Handshake_Control')
self._handshake_control.reset = nop
self._on_handshake_response.subject = self._handshake_control

I don't know enough about Ableton to know what send_value() to a control does. I gather this might be in the methods for the parent class (which I gather is a button and probably described in the control_element_util library).

So, I decompiled the control_element_util.pyc from the Midi Remote Scripts and found this:

def create_button(identifier, name):
return ButtonElement(False, MIDI_CC_TYPE, MIDI_CHANNEL, identifier, name=name, skin=skin)

Higher up in the script the MIDI_CHANNEL is fixed to 15.

So, it really would seem that the handshake is sending 00 as a MIDI_CC message to channel 15. I don't know where to find the ButtonElement class (seems its in ableton.v2.control_surface but I can't find that).

I think I found ButtonElement, and more importantly it's underlying InputControlElement class (in InputControlElement.pyc). The relevant methods for send_value are here:

def send_value(self, value, force = False, channel = None):
value = int(value)
self._verify_value(value)
if force or self._force_next_send:
self._do_send_value(value, channel)
elif self.send_depends_on_forwarding and not self._is_being_forwarded or self._send_delayed_messages_task.is_running:
first = 1 - self.num_delayed_messages
self._delayed_messages = self._delayed_messages[first:] + [(value, channel)]
elif (value, channel) != self._last_sent_message:
self._do_send_value(value, channel)
self._force_next_send = False

def _do_send_value(self, value, channel = None):
data_byte1 = self._original_identifier
data_byte2 = value
status_byte = self._status_byte(self._original_channel if channel is None else channel)
if self._msg_type == MIDI_PB_TYPE:
data_byte1 = value & 127
data_byte2 = value >> 7 & 127
if self.send_midi((status_byte, data_byte1, data_byte2)):
self._last_sent_message = (value, channel)
if self._report_output:
is_input = True
self._report_value(value, not is_input)
return

[_Stevie_]

Hey DrFrankencopter,

got Live working with the KK S-88.

I just checked your findings, I'm not 100% sure if it is relevant to the MK1, because
the use of the MK1 still makes it necessary to install the py host files from the NI folder. However, the MK2 doesn't, It works out of the box, because the files are included with Live 10. Still digging...

[DrFrankencopter]

I managed to get the transport buttons working in Live. But I can't even figure out how to name a track, so testing instance following and the nav buttons is something I can't do right now.

What I did see while running Live and MidiOx at the same time was that while Live was able to correctly illuminate the transport buttons I did not see these messages in MidiOx. All I could see there was the button on/off state changes.

Are you able to see these midi exchanges in MidiOx?

The komplete_control_base file that I decompiled is provided with Ableton, and isn't part of the NI package. I think it implements the other (host) side of the transaction; but I really don't know for sure. I can say that there is lots of breadcrumb evidence that Mk2 is handled differently.

[_Stevie_]

I haven't bothered for anything else than the transport, yet, lol.
Because I think that's the key, setting the KK into "deep mode".

Yes, I can see pretty much every transport command.
That's how I set it up:

[_Stevie_]

I could be wrong, but to me it seems, that the somehow the NIHIA is getting the info: dude, we have an Ableton Live session here, put yourself in Live mode. That's why there can only be one DAW to control the KK S-XX.
When you turn off the NIHIA service, all this doesn't work anymore. So to my understanding there must be a way to communicate with the NIHIA (1 the 3 cases
brummbear pointed out).
Will look further for more evidence... I somehow think there is some OSC going on, but not sure, yet.

[_Stevie_]

Well, some new insights...

I removed the _NativeInstruments and the _Komplete_Kontrol folder from Live
and just kept the Komplete_Kontrol_Mk1 folder. And transport is still working.
So, I guess it MUST all be in the remaining scripts from the Komplete_Kontrol_Mk1 folder.

[Funkybot]

I just picked up a Komplete Kontrol M32. ReaKontrol version .95 and .96 will crash Reaper almost immediately in an empty project. Versions .94 and prior work without crashing. Using Windows 10 and Reaper 6.08. Latest firmware for the M32.