What the heck. Just rebooted a few times, changed USB port, and it lit up again. After I tried it on another Zynthian where it also did not work… yet now it does. Flakey bastard…
Can’t say I’ve been massively impressed with the behaviour of my Akai MPK Mini.
It has fits of amnesia about MIDI channels and the keyboard has sulked in the past. Not suitable for live.
Hi Akai APC Key25 users!
I have refactorized the Device Mode for the APC KEY25 family of drivers in Vangelis.
Old code was too hard to maintain as it re-implemented the UI buttons & LEDs logic.
I’ve rewriten the device mode to re-use the core UI logic, so any change in the UI logic would be reflected by the driver without need to change the driver’s code.
Please, note it needs a V5 layout or the V5 Touch Buttons enabled to work (touch buttons can be hidden)
Note for developers: This mode should be “abstracted” in a base class, so any driver can implement the device mode easily by simply defining the notes for the buttons/leds and the CC numbers for 4 knobs.
Ahhh! I forgot to say that i don’t own an APC Key25, so the new code probably don’t work. I hope some brave user+developer (@niels, @oscaracena?) could help me to fix what is wrong. All i can say right now is that the driver is loaded, but i couldn’t enable/test it.
The commit.
Regards,
Hi @jofemodo .
This is something I have wanted for some time, to just use v5 logic directly.
I spent a few frantic hours last night to make it work again (it was pretty broken, with pads doing wrong things and other pads lighting up).
Most of it works again, so people just updating are not completely baffled.
This brings back most parts of the device driver @jofemodo fabulously broke yesterday :).
There were undefined references, a .get() on a list, and incorrect mapping.
Things I did not yet get working:
- Pad for tempo screen/tap tempo does not work yet. And blinking will be interesting too (on active metronome).
- understanding zynswitch in numbers versus led out numbers (they are not the
same?!). I could not find where these numbers are documented. Some named constants would be awesome. - understanding arrow keys (should be able to do with zynswitch too?)
- checking/fixing apckey25 (first gen)
- checking/fixing other pads/buttons (dedicated rec/play, zynswitch
small/large steps on acpkey25 1st gen, more? - Gotta check exactly the interaction with v4-layout + v5 touch.
NOTE the original driver only lit up rec/play whenever there was something recording/playing. And STOP never. I kinda added that behaviour again, not fully, and wonder whether we should just follow v5 in this respect. Also the pads were just tallies, because there are dedicated rec/play buttons on the device. Need input on that (decision-wise).
Seeing the open questions, there will be more changes to come, but here is the PR to get it back on track again.
I am now on a camping trip for the weekend, but please share some ideas on how to do the stuff above.
Oh, and I noticed that ALT mode does not work on the zs3 screen, meaning you can not use F1-F4 to send Program Change 5-8 there to save a zs3 to a PC.
Ups! This is due to a recent change. I will fix ASAP.
BTW, i bought an APC Key25, so i can test my code before commiting ![]()
And you can play with SooperLooper ![]()
Fixed! Please update & test.
No Zynth in sight alas. But I’ll check when home. Other people may test.
Enjoy the camping, mate!
Okay, I think I know why tempo does not yet work. In zynthian-sys/config/zynthian_envars_V5.sh
it only has an action for Push, not Short, and - still using the ButtonTimer we do not have the concept of Push in the driver. Same for the arrow keys.
This is needed for tap-tempo.
Regards,
Tested. Works. Am I right that every screen now has its own alt-mode (no global alt mode anymore)? That may indeed be easier to reason about (both in code and from a UX perspective).
And why is F1 in mixer/sequencer orange instead of purple? It does not seem to do anything especially special (just PC#5).
May I ask, because with the API changes in vangelis some things became rather confusing:
In each of the APC 40 and the APC 25 Key, is there a working state as well as active development to both the MK1 and MK2 versions right now?
Or in other words: If someone wanted to buy one really well integrated controller, which one would ot be? Just asking because you pretty much find an APC25 MK1 everywhere, even in the direct neighbourhood for as low as 30€, but probably it wouldn’t work.
Lemme check…, I tested and fixed mk2 so far, leaving mk1 to fix latest.
Mk1 mostly works, but:
- Device Mode is now a sea of green.
- Cannot get back from MixPad to device.
I’ll probably be able to fix this later this week.
And I found some strange communication happening between mk1 and mk2 when both are plugged in.
My advise is if you can get a very cheap mk1, fine, it’s sturdier than mk2 (some leds are beginning to fall out in my mk2) but:
- less colors (just three). And brightness is always at 100%.
- (absolute) pots instead of (relative) encoders can be annoying.
That’s the reason to go for MK2, thanks. And to be honest, even a new MK2 is not exactly overly expensive.
But in general, concerning these controllers: As far as I can see mk1 and mk2 ctrldev drivers are completely independent from each other, right?
for the apckey25: mk1 is subclassed from mk2, so main development is on mk2, but changes should trickle down.
So mk1 is dependent on mk2. Sometimes this leads to bugs, such as the sea of green, where mk1 is using mk2 colors, and anything higher than note value 5 or something is interpreted as green. Easy to fix though.
I understand.
Things like this probably:
yup.