We don’t tend to commit IDE configuration files so each developer may use the tools that best suit them. The wiki page was written to offer an example of how to do things, mostly recording the author’s experience. I mostly use vsc now, running on a Chromebook (or other laptop) and connected via ssh. The code runs on the real zynthian with editing, debugging, etc. all presented on the local laptop. It works well must of the time. I do to text editor sometimes, mostly vim because I was taught basic vi in the 1990’s and have the muscle memory for it. (Damn the default enabled plugins on later versions! I am looking at you, “visual mode”.)
There is no official way to code but there is the standard git pull request method of submitting code to the project.
Be careful to store your code before and normal update, else you will lose it. (It is rather disheartening when this happens.) The best way is to use git how it’s supposed to be used… good luck learning that!
Regarding CC assignment, use the most likely default setting of the device. We prefer to avoid the need to configure a device to work with zynthian, preferring zynthian to work with the out-of-the-box device. For the LaunchKey driver I send commands to set it to DAW mode and set the knobs to a known state then support the user changing the knobs to fader, pan, device, etc.
To avoid this kind of tragedy, i rarely edit the files in the zynthian device directly.
Editing the code files locally in your workstation and copying to the zynthian device to test is the way i do. This adds an extra step to my workflow (copying the modified files) but this also have some advantages:
SD cards are less stable/reliable than my workstation RAID.
Zynthian’s update scripts are quite destructive with modifications.
git pushes from the zynthian device needs extra config. You can’t do It from a fresh burned image.
you are more conscious about changes because you are copying the modified files all the time.
it’s easier to test the code changes in several zynthian devices before commit.
Yeah. I get the general idea. I am just somewhat conflicted between leaving it on Preset 1, which is named LiveLite, versus one of the ones that is just MIDI Out or Generic. The former is, de facto, the “default”, but in reality, most people would think of the latter two being baseline. As it stands, the Ableton / LiveLite assignments feel much neater. So, I guess that I will lean that way if there’s no input to the contrary.
Just a quick update. I did get the driver “working” in a very basic form some time ago. However, I have been distracted by many things, including the newly released Ardour 9 release candidates, which sort of pulled my mind in a different direction in terms of looping/ideal setup, etc.
Regardless, one thing that I figure someone will likely know the answer to…as it stands, when I load the drivers…the newly mapped functions of the knobs (encoders?) and faders work as intended. However, until I uncheck the driver, it no longer allows the keyboard to be selected as a standard MIDI source for notes. I am guessing that there is a certain parameter or class inclusion that I don’t know, which would make all right in the world again. If I could get past that hiccup, I would probably be a lot more motivated to make more progress. Thank you all for the help to get this far. I really hope to get something more proper available in the first couple of months of 2026.
Hi @jigglydad - I’m guessing also, and I could be way off here, leading you down a path that is not really related to the issue you’re experiencing, but I’ll pass along some bits of Akai driver support info that I learned when I was initially trying to get my Akai MPK225 and Akai APC Key 25 mk2 working with Zynthian Oram. I think the MPK225 and MPK249 are conceptually the same for purposes of this post, the 249 has more keys, and thus more panel space so they gave it more controls as well. The APC Key 25 is different, as shown in the ‘device list’ below:
The difference to note is that the APC Key 25 shows up as 2 devices, K for the Keybed, and C for Controls, where the MPK225 shows up as a single USB-MIDI device. So the APC can use a Control Driver for the controls, and the Keybed still works with Zynthian, unlike the MPK225.
I think that for the MPK249 to supply MIDI notes once the driver takes over you will have to process them in the Control Driver and pass them along to Zynthian. I know that’s awfully vague, and it’s also guessing on my part, but I hope it helps.
If there is but one device showing up, my guess is it works akin to the akai apc key 25 first generation. This uses a different MIDI channel for the keybed. The class variabele `unroute_from_chains` can then be used as a bitmask for the channels to unroute. See the driver for apc key 25 first gen (not mk2) for an example.
I’m currently thinking about some kind of assisted vibe coding to get some functions for the MPK225 driver. We’ll see how that goes… The result should be at least adaptable the 249.
But what I found useful was to fire up a
aseqdump -p MPK225>> midictrl.out
and then operate each and every control of the MPK225, from min to max values, over all banks, including wheels and keys. That gives you at least a good overview how your Controllerdevice is configured and which features are usable.
If I had enough time, I’d try to take the syx file of my current configuration, change a setting, download a new syx file and compare to learn which part of the hex syx file has changed. Document and repeat with all other settings. Finally we would get a full documentation about where in the syx files which setting is configured, and we could generate a syx file with a working configuration… alas I don’t have the time…
Hi @jigglydad - did you get past the “hiccup” with @niels ‘s suggestion: “The class variabele `unroute_from_chains` can then be used as a bitmask for the channels to unroute.” above?
Which preset did you decide to write for?
Any notes or thoughts on the Ardour 9 release candidates that were among your distractions?
Hey. Sorry…. I ran into some serious snags trying to upgrade the GPU in my main PC, which has unexpectedly required ended up requiring me doing a ton of data moving, partitioning, etc. So, my usual project time has been eaten up trying to keep things moving….not to mention the crazy snowfall and taking in a dog that turned out to have fleas and be in heat. So, as of now, I am no further than I was last time I posted.
As for the Ardour stuff, I am excited that version 9 is near, but the lack of documentation as to how most of it is supposed to work prior to the actual release, it is hard to say much. They’ve been doing a great job squashing the most-obvious bugs, but hard to say whether it is up to the task of truly doing Ableton-style looping yet.