Arturia Keylab MKII: some help understanding what happens and maybe an API bug

Hi,

I'm trying to solve what looks like a bug in the Arturia Keylab MKII 49 controller script.

Context:

this controller allows to select a track and solo it (pretty standard)
there are two ways to select a track
- either by scrolling with a big wheel in the center of the device
- or by pressing one of the eight available mixer slices' selector button (selects position 1 to 8 in the current track bank)

Expected behavior:

solo button should solo the currently selected track

Actual behavior:

🟢 solo button works when track was selected using the scroll wheel
🔴 solo button does nothing when track was selected by pressing a button selector (even though the UI displays the track as selected)

The code:

what seems to be the code executed on solo press:

bitwig-extensions/src/main/java/com/bitwig/extensions/controllers/arturia/keylab/mk2/ArturiaKeylabMkII.java

Line 332 in 00af36d

layer.bindToggle(ButtonId.SOLO, mCursorTrack.solo());
what seems to be the code executed on wheel scroll:

bitwig-extensions/src/main/java/com/bitwig/extensions/controllers/arturia/keylab/mk2/ArturiaKeylabMkII.java

Line 387 in 00af36d

layer.bind(mWheel, mCursorTrack);

what seems to be the code executed on button press (needs to be in Multi Mode, that's a detail):

bitwig-extensions/src/main/java/com/bitwig/extensions/controllers/arturia/keylab/mk2/ArturiaKeylabMkII.java

Lines 451 to 461 in 00af36d

    
           for (int i = 0; i < 8; i++) 
        
           { 
        
              final ButtonId selectId = ButtonId.select(i); 
        
              final int number = i; 
        
              final BooleanValue isCursor = mCursorTrack.createEqualsValue(mTrackBank.getItemAt(number)); 
        
              layer.bindPressed(selectId, () -> mCursorTrack.selectChannel(mTrackBank.getItemAt(number))); 
        
              layer.bind(() -> { 
        
                 return isCursor.get() ? WHITE : mTrackBank.getItemAt(number).color().get(); 
        
              }, selectId); 
        
           }

Observations:

It seems that binding the wheel to the CursorTrack (bullet 2) does something more than what selectChannel() does (bullet 3) when pressing one of the buttons. Because then solo() (bullet 1) works.

API Reference:

The CursorTrack class seems to implement Cursor and CursorChannel. The former offers selectPreviousAction() (and its counterpart) but the latter only offers selectChannel().

select(Previous|Next)Action() is implicitely executed on wheel scroll (by layer.bind(), that's my guess)
selectChannel() is explicitely executed on button press

I'm guessing in the first case something happens that makes solo() work, and it's missing in selectChannel().
So the issue could as well reside in the Controller Script API, in other words I can't fix it by myself.

What next?

Could you please help me understand this and point me towards the right direction?

Thanks 😄

Just ran into same issue. Using 8 buttons to select track breaks solo, mute and arm buttons. Thinking could be fixable by calling selectNext/Previous multiplte times or by remapping those buttons to scroll the cursor track instead. Or use them for anything else because now they are broken

Not an API bug, using MidiView I realized that pressing one of the 8 SELECT buttons will change what MIDI mute/solo and arm send out. I will make a pull request for a patch that maps different button note codes correctly.

	for (int i = 0; i < 8; i++)
	{
	final ButtonId selectId = ButtonId.select(i);
	final int number = i;
	final BooleanValue isCursor = mCursorTrack.createEqualsValue(mTrackBank.getItemAt(number));

	layer.bindPressed(selectId, () -> mCursorTrack.selectChannel(mTrackBank.getItemAt(number)));
	layer.bind(() -> {
	return isCursor.get() ? WHITE : mTrackBank.getItemAt(number).color().get();
	}, selectId);
	}