I’ve read both Launchpad X and Lanchpad mini as they are formated the same way. They look exactly the same (exept he “0D vs 0C”), line after line (but the X avec more functions).
I’m looking the ID side, as my windows computer do not have the same ID…
Anyway, have fun with your family first !
Fun thing : I was in Paris last week and came back home Britain since… as you can see with my discourse activity 
If your trip lead you near the Ocean, make a call 
BOUM ! 
dev_ids = ["Launchpad_X_MIDI_1", "LPX_DAW"]
And it doesn’t work with “LPX-DAW” alone, but does work with “Launchpad_X_MIDI_1”… i’ve kept both…
Super nice!! Congrats!! Please check that other buttons work as supposed (scene change, arrows, etc.), make the needed adjustments, if any, and make a pull request with the new driver.
Thanks a lot!!
And enjoy your new toy… you deserve it!
Arg, I’m away for work !
You can find it attached to my post just above, is it okay for you ?
It is with your name on the copyright chapter because… You did 99.99% of everything write on it. I have just made tests in the end. 
OK! As you want, it’s now added to testing branch
So the list of supported devices is now:
We have 6, but we want more, many more!!!
Enjoy!
As @rockinlord mentioned before, the Launchkey Mini Mk3 integration seems a bit broken atm…
I ran into the same issue, the LED feedback is correct, but there’s no way to trigger pads.
Functional transport controls would also be really nice.
I’d like to propose some interface for selecting the control surface for each connected controller.
Default scripts (using device IDs) are great and should still automatically be selected for new devices.
For development and user convenience however, I feel like there should be a list of selectable control surfaces for each controller, since users might want customize their behaviour, try some things and still be able to revert to default without having a PC connected at all times…
Pretty much every DAW with control surfaces also offers this kind of selection. Here’s Ableton Live:
Edit: Regarding the Launchkey Mini Mk3, I might take some time soon to update the control surface 
I’ve not a launchkey controller to debug. Perhaps @riban want to take a look
You are right and it’s in the roadmap. As soon as we have several drivers/scripts for the same controller, i will have the motivation for implementing this
For instance, it would we lovely (and very fun!) to have a kind of “pattern editor” surface using a launchpad controller
Regards!
Helloooow, Do you think we can have the top right led of the launchpads, under the logo, blink to the beat ? Green red red red Green red red red ?
I’m trying to write a driver to use the Akai APC 40, I’m starting as a mixer, then moving on to pad integration. I was able to get basic debugging working using vs code connecting to my zynthian remotely, but I don’t ever see the zynthian_ctrldev_manager or my device definition even loading. I’ve set breakpoints in the files, zynthian_ctrldev_manager.py and my ctrldev/zynthian_ctrldev_akai_apc40_mixer.py, but they never trigger. I’m sure I’m probably missing something basic. Is there some setting to enable the ctrldev manager or something?
Ctrldev_manager is always enabled and tries to autoinit a matching driver of each type (zynpad and mixer) when possible. If the ID string of a connected device match the ID strings from a driver, the driver is initialized for mixer or zynpad, depending on the driver type. I’ve not tested to put together mixer & zynpad functionality in the same driver. It should be possible but you could find problems or limitations. The driver model is being currently improved to allow greater flexibility. Meanwhile, focus in a single type first, mixer or zynpad.
Regards,
I’ve just got a basic driver working for the launch pad controls on the APC40 - you can see the code here in case that gives you any leads for the mixer side of things: GitHub - lyserge/zynthian-apc40: Akai APC40 controller driver for Zynthian
p.s. thanks @jofemodo for putting this subsystem together! Hopefully this will open up a whole lot of hardware compatibility
Thanks @jofemodo and @lyserge! Lyserge, I’ll be taking a look at your implementation of the the apc40 to zynpad. Thanks for getting me started!
Thanks again for the link, it absolutely helped me get started! I was able to use your code and get an implementation of both the zynmixer and zynpad working on the APC40 mkI - there’s still a couple of bugs but it’s mostly working - GitHub - zhagan/zynthian-controller-drivers: To how
Hi!
I’m working on a controller device driver for the Akai APC Key 25 mk2:
Is there someone else working on it? If so, we may join forces. Otherwise, I’ll update as soon as I have anything working 
Best regards!
UPDATE: Mixer volumes ready! I can control the first 8 channels directly with knobs 1 to 8, and channels 9-15 with knobs 1 to 7 + SHIFT. The shifted knob 8 is for main chain (master volume).
UPDATE 2: Mixer pan working! Pressing SHIFT will lit the selected function for the knobs (currently Volume or Pan), and using the Knob Ctrl buttons you can change the function. Pan (balance) knobs works as volume does.
UPDATE 3: Now I have the mute/solo buttons ready! They are controlled by the Track buttons (button row below the pad matrix). Pressing each one of these buttons will toggle the current selected function for the corresponding chain. As there are only 8 buttons, I’ve implemented a bank function: pressing SHIFT + LEFT/RIGHT will change between bank 0 (chains 1-8) and bank 1 (chains 9-16). The triggered action is selected by the Soft Keys (button column to the right of the pad matrix). Pressing SHIFT + MUTE/SOLO will change the action. Also, the Track buttons will lit if the corresponding function is active in the given channel.
I think the mixer functionality is complete. I’ll give a try to the Zynpad
Hi again!
I’ve a problem: when I press any control key (which are handled by midi_event, returning True) the event is propagated to the selected chain, and if it is a MIDI one, it produces a note. How can I control (avoid) this behaviour? Any clue? 
It shouldn’t happen. When a driver is loaded for a device, the device (MIDI port), this is disconnected from the chains. Are you using latest testing branch?
You should see this logging message when your device driver is loaded and enabled:
logging.info(“Setting-up {} in slot {}”.format(self.dev_id, self.idev))
Could you tell me what’s the exact logging message you get?
Also, how many MIDI devices use the controller? Have separated MIDI devices for control and playing?
Regards,
Are you using latest testing branch?
Yes, I’m using the ‘testing’ branch, and I’ve updated everything as well.
Could you tell me what’s the exact logging message you get?
Yep, is this:
INFO:zynthian_ctrldev_manager.setup: Setting-up APC_Key_25_mk2_MIDI_2 in slot 2
Also, how many MIDI devices use the controller? Have separated MIDI devices for control and playing?
Yes, it has two devices, called port 0 and 1, which are MIDI 1 and MIDI 2. Port 0 is used only for the keybed (white and black keys) and for the sustain button. The rest of the buttons, and also the LEDs are in port 1 (MIDI 2).
Thanks for the response!
Could you send your driver’s code? I would review it.