Akai APC Key25 mk2 driver

Software
101

Bold press there, and enable your driver in the menu that appears…

102

image
image812×496 84.5 KB

I can change the Midi Input Mode or the Configuration, but I cannot activate the driver

So I guess I miss something since the driver is not available

103

Then it may be a mismatch with the IDs. Did you see exactly the same label in the logs and in your dev_ids? Did you set the ZYNTHIAN_LOG_LEVEL=10? Maybe trying with APC Key 25 IN 1…

104

You are right

these are the correct ids
image

and eventually

image
image813×486 78.9 KB

Thanks a lot for your support … I will play a bit with it to see how it works and I’ll keep the community updated

3 Likes
105

Congrats! You fix It
Make a PR with the fix, please.

Regards

2 Likes
106

I will … let me check everything is working as expected and I’ll make a pull request.

regards, Andrea

107

Assigning an instrument in Step Sequencer Mode does not work for me anymore. I have not played with that mode for a while, but I just updated Oram.

I do not see anything related in @oscaracena’s last two commits. My apc did fall on the ground, but everything else just works as it should (including pad/button combos).

So I was wondering whether anyone else has this issue. Maybe it is something outside of the driver. The device driver binds to the second ‘device’ the physical device offers, but the notes (black and white keys) come from the first ‘device’ - which has no device driver tied to it.

108

I think something changed in the assigned midi device ids.

The code assumed the keys had a device id lower than 2, with me it is currently id 6, and the pads and encoders (for which the ctrldev driver is made) have id 7.

The code says the following:

        # FIXME: if MIDI is playing, we need to ensure this note_on does come
        # from a device (i.e the user pressed it!). Current FIX allows using only
        # the APC itself
        if izmip > 2:
            return

Changing the last line to the following works

        if izmip + 1 != self._own_device_id:
            return

Changing the check to see whether the device the played notes come from has an id of 1 lower than the current device solves this issue, but I am uncertain as to whether this is a very stable solution. And as is written in the FIXME: what is actually wanted is to listen for any device-based note_on (except for note_on coming from the pads themselves).

Is there a mechanism we can use to check this?

109

Try this:

if izmip >= self.chain_manager.ZMIP_SEQ_INDEX:
    return

This should ignore notes coming from sequencer, MIDI player , etc. but will process notes coming from any other device.

Regards,

110

izmip are dynamically allocated. You can’t assume that the device will always have the same idev. It depends on what is connected when and the result of the initial emumeration and consequent USB hot-plug.

zynthian_ctrldev_manager handles midi events and only sends them to drivers that are registered for the idev the message was received. The idev reaches zynthian_ctrldev_manager but is not subsequently passed to the driver’s midi_event handler.

The driver is passed the idev during initiation and should only get MIDI messages from that idev.

111

This part of @oscaracena’s code does not rely on zynthian_ctrldev_manager, but directly on zynsigman, so it does receive every little thing:

def _enable_midi_listening(self, active=True):
        func = zynsigman.register if active else zynsigman.unregister
        func(zynsigman.S_MIDI, zynsigman.SS_MIDI_NOTE_ON, self._on_midi_note_on)

This is necessary because the pads and buttons reside in one idev, and the keybed and sustain button are in the other.

Is it safe to assume that the idev does not change after initialisation?

112

idev is assigned to an input when that input is detected. It will remain valid throughout the life of the device driver. If a USB device is replugged then the driver will be unloaded, idev will be calculated and driver reloaded with new idev. (If this does not happen then it is a bug!)

113

Thanks, that’s stable enough then. As for @jofemodo’s suggestion,
self.chain_manager.ZMIP_SEQ_INDEX does not work (it both being _chain_manager, and ZMIP_SEQ_INDEX on self._chain_manager being undefined.

The following does however; is this correct usage?

self._state_manager.get_zmip_seq_index()
114

Yes. This should work.

Regards,

115

Good, I’ll submit a PR to oram then.

116

Thanks @niels for fixing it! :slightly_smiling_face: :clap: Please, submit it also to Vangelis, so we don’t have regressions!

117

Okay, I did so, although that seems a bit double. What do our beloved gods have to say about multiple PRs on the same issue?

118

PRs to Vangelis. We would move to Oram after testing :wink:

Thanks!

1 Like
119

It’s merged in vangelis.

1 Like
120

Hi, I made some tests. It seems that most functionalities work as expected. Only evident issue is on the color feedback on the pad.

I tested the protocol available here https://cdn.inmusicbrands.com/akai/attachments/APC%20Key%2025%20mk2%20-%20Communication%20Protocol%20-%20v1.1.pdf

#!/bin/bash
midi="90 01 50"
amidi -p hw:2,0,0 --send-hex=$midi

and it works!

So I have to better investigate why it is not working in the driver

Should I submit a pull request clarifying color feedback is not working as in mk2?

Regards, Andrea