Having recently acquired a Zynthian 5.1, I am looking to get more out of my AKAI MPK249. I see that there is already a driver for the MPK3 Mini and a couple of other AKAI devices. Has anyone done any work on making a driver for the MPK249 ? If not, from what I have read, it seems like something I can probably tackle, but I haven’t tried yet. Any general tips on doing this would also be greatly appreciated. Thank you!
2 Likes
Hi @jigglydad, I hope you enjoy your Zynthian! 
From my experience with Akai, it could be a breeze or more cumbersome, it depends on the internal implementation of the device (not every Akai device is implemented the same way) and the available documentation.
I would start with just the simplest boilerplate code, to check if it gets loaded and such. And then, using other drivers as reference, go adding features bit by bit, testing them as much as possible before going to the next one. Depending on how many features you want to add, it will be a more or less long journey.
I’m sorry, but without having the Akai MPK249 myself, I can not be of much help. But if you try it, please keep us informed about your progress! 
1 Like
Hi Oscar,
After many months of putting this off, I finally started trying to do this during the past week. I installed VSC, got it working connected remotely, but as of yet, I am still stumbling to get over the hump just getting started. I would be very appreciative if you were able to tell me some of the basics for getting started, specifically what the required fields are to get a driver loaded.
I have been banging my head against a wall, just trying to figure out basic things like that, and it is preventing me from getting anywhere.
I have also been trying to figure out what constitutes the device running in its default state, since it has many banks of presets for different DAWs. I believe that out-of-the-box, the Ableton one is loaded automatically, and it has very different assignments of the knobs, faders & buttons than things like MidiOut and Generic (which seem like they would be more of a starting point).
Any thoughts are appreciated. I’d love to knock out at least getting this whole thing working in the next few days…and then tinker with it over the coming week or two.
Thank you.
1 Like
I own an Akai MPK 225, smallest version of the 249.
I also started to work on a driver some months ago and at least got it initially loaded.
But no special features as of yet. Lack of time… But that maybe get you started.
You will need to change dev_ids and names. Otherwise I also thought about the possibility to build it for all 3 MPKs as I thought it doesn’t make much sense to have 3 different drivers for nearly the same devices…
3 Likes
Thank you very much for that. Fingers crossed that I can get it loaded tonight.
While I like your idea in theory about one driver for multiple devices, I am probably not knowledgable enough to know what I am talking about, but I am wondering how that would work. It would appear that the MPK249 has twice the pads, knobs and faders, amongst other things. I was imagining that quantifying and assigning these was among the more important aspects of a driver.
Please let me know your thoughts. I definitely feel out-of-my-depth, even though I presume that I can muddle my way through, particularly after you pointing me at what you’ve done.
I’m sadly left scratching my head over here. I must be missing something really obvious. I have tried so many different iterations of dev_ids, with your code and with other code, and nothing seems to make this load.
I did uncover one thing that confuses me…and I thought would be helpful, but so far, it has not been. I note that the dev_ids for the Mackie Control and Fostex Mixtab, which always show up as options, are wildcards. After changing those, I was able to make them go away as options, but I was not able to get my own driver so show up by giving it:
dev_ids = ["*"]
So, I have questions after that.
- Is that intentional?
- If so, why?
- Why doesn’t my own driver load when trying to use the same trick?
Mackie Control and Fostex Mixtab allow connection via DIN-5 which does not provide a device name, like a USB MIDI connection does. The wildcard allows the device driver to appear as an option in the list for the user to manually enable as the feel fit. (We should probably add a configuration to hide unwanted ones to avoid the list being too long as we add more…)
If your device driver is not showing up, even when using a wildcard in its list of device ids, there is likely something wrong with the code that is stopping it being recognised or running (are there any clues in the log?) or maybe in the wrong location or called the wrong thing. Ensure the source file is in the ctrldev directory and has the same filename.py as its class name. Ensure it implements all the required methods and returns valid values where necessary. Check for syntax errors and bugs in the code (check logs). Start with a minimal example, e.g. copy another simple driver, then add functionality when it is working in at that basic level. (I almost always start every project with a “hello world” bit of code, then expand to add functionality. (An after doing this for decades, I still make mistakes with that basic hello world boilerplate!!!)
1 Like
Two things to check:
- Any syntactical errors in your file
- Is the class name exactly identical to your file name (it should be)
journalctl would nag about both, and other errors.
1 Like
You beat me @riban!
Wow. Thank you. Perhaps I could have found this information elsewhere, but I had no idea that the filename needed to precisely match. I was not even attempting to match that. I was solely focused on dev_ids and other similar things.
So, now the actual work begins, I guess. Many thanks.
If anyone wants to chime in on my other annoyance atm, which is that I can’t seem to get the public/private key sign-in 2 work, which makes me have to go into my browser and copy the password from BitWarden every time I reboot the thing. As many times as I have been rebooting it, trying to make this work, that has actually been a major frustration. 
Sign-in to what?
I installed VSC specifically for this. I have never used it before. So, I was able to follow directions well enough to get the remote part working, but I have to use a password each time. It is my understanding that the way to go is to just sign in with a key… I thought I followed those directions, but apparently I messed that up as well.
Having said all of this, I am guessing the answer is to check the logs. But, I am still more of a noob about such things than I care to admit.
Edit: Short answer is….the Zynthian.
You want to get SSH login working with a key so that you can connect from the command line without being asked for a password. When you get that working then you can get vsc using the same key.
Hi @jigglydad
This reply from tunagenes helped me to better understand how to develop for Zynthian.
I must say that using VSC is only one of the many options you have.
Indeed, i never used it and never missed it 
I like to work with a good text editor, but i don’t like IDEs. In the past i used kate and in the last years i’m quite happy with pycharm (just as a text-editor, mostly ignoring IDE options).
For running/testing the code, i like to use a real zynthian device that i access using SSH from terminal.
I use debian with default gnome desktop in my workstation. While working i keep this stuff opened:
- Text editor (pycharm) with zynthian code
- Terminal connected to my test zynthian device (normally V5,sometimes V4 and others)
- File browser window with local code files
- File browser window with zynthian device code files (i use SFTP)
My “standard” workflow is like this:
- Edit files locally
- Copy modified files to zynthian device. Simply drag and drop files from a window to another. In the past i used grsync, but it’s slower and manual drag & drop is normally more agile most of times.
- Run modified code in the zynthian device. When modifying UI, i like to stop zynthian service and use zynthian.sh script to start UI by hand and see the logs in real time.
- When done, git commit + git push from command line.
Of course, i also use variations. For instance:
- Sometimes i like to run the zynthian UI in my desktop computer directly, avoiding to copy modified files to my zynthian device. This is specially useful when testing look & feel changes that requires a lot of adjustments.
- When i need to access python debugger => zynthian_debug.sh script
- Etc.
The good of using this workflow is that i don’t need to setup anything to work from any computer, specially if it’s a linux computer. I can live with other text editors, including vi or joe. It’s simple and direct. It always works.
Obviously, IDE lovers will prefer to work in different ways, and it’s perfectly OK too. Up to you!
All the best,
3 Likes
I just realized that I managed to do everything backwards with the private/public keypair. When you do things the right way….amazing what a big difference it makes. 
So, the two biggest hurdles are down. 
3 Likes
I knew there were other ways to do this, but when I went to the official instructions, that seemed to be what was being suggested, so I was just doing my best to be in a somewhat standardized environment. In areas where I am more familiar, I also tend to do my own thing (and avoid Microsoft, of course). But, since I had taken so long to even get to attempting this, I was just trying to do something standardized.
This DOES lead me to my other lingering pain point…. I have never actually done any coding for any open-source projects that I can recall. So, while I have heard the terminology of pull requests, commits, etc., I would be lying if I said that I truly have a grasp of how to do any of that. I had assumed when I updated the software on my device, that I would lose the driver, which seems to be exactly how that worked. So, now that I am in the stage of actually trying to do things that I don’t want to lose, I probably understand what I need to do to avoid having that be lost during an update (obviously, keeping a local copy is certainly one answer, but I might rather that be the backup).
I am presently running on Ubuntu Studio 25.04 (the updater to 25.10 went out the door broken, and I have not actually managed to get it to work manually). Again, this was my way into doing music on Linux that worked with the least fuss. But, I am quite inclined to go in another direction at this point. My biggest stumbling blocks are needing more storage on my NAS to feel like I truly have everything backed-up properly….and not having a great comfort level with distro-hopping.
I will say that centralizing my music more on Zynthan than on my PC is allowing me to think of things in a different way, though. Once I can get everything locked-in there, I will feel more freedom to change distros.
Thank you so much for all the input.
One more inquiry that maybe someone will have some insight for me by the time I work on this again tomorrow….
We are encouraged to have the driver function in the device’s default state. Technically, when you start this device up the first time, it is in Ableton mode. I was making the assumption that it would be best to work in one of the more generic modes, but it seems like those modes have some rather annoying MIDI assignments:
3 - Knob 1
9 - Knob 2
14 - Knob 3
15 - Knob 4
16 - Knob 5
17 - Knob 6
18 - Knob 7
19 - Knob 8
Is there an obvious and/or practical reason for the gaps between knobs 1, 2 & 3? And since the Ableton settings are consecutive from CC22-CC29, perhaps it is better to just start there? All thought welcome. I’d just rather start out making the right assumptions than do something silly and have to re-do everything again.
Thank you again to everyone for getting me moving.
What I do is fork the zynthian-ui repo (on Github for instance, which you’ll eventually want to do anyway once it’s time to create a pull request).
Add that as a remote. Push to that remote.
When you want to get changes from the branch your dev branch is working off, first make sure you pushed your changes to your own remote.
From within Git on Zynthian (possibly from the confines of VSCode, if that suits your ilk) change back to the official branch (not from the webconf - I have had issues of local stuff being gone that way, cannot remember exactly if that were branches or stashes or something else).
Then perform an update from webconf. This handles anything other than plain updating of the source.
After the update, change back zynthian-ui, merge the changes into your own branch, and restart (zynthian ui, or the entire device).
There is no such a thing like a “standarized” or “official” way. I think the wiki is not clear enough. i will fix It ASAP.
Thanks
2 Likes