Hi people in the Zynthisphere,
Here I present the ports of the two ctrldev drivers (without and with SooperLooper support) from mk2 back to the gen 1 version of the Akai APC KEY25.
It was quite some work to be frank, mainly because the gen 1 is just quite less capable then the mk2 version. If you don’t own one of the two yet, just get the mk2.
First: We have but three distinct colors, and just full brightness. So I had to redesign stuff, lie a little bit here and there, etcetera.
The PadMatrix looks really empty when there are no sequences defined yet (all leds off).
All blinking and pulsing levels is just blink (slow).
The, in my heart, quite mnemonic use of colors in SooperLooper modes went a bit down the drain. The pad in the same column as the action is now blinking when its (recording-type) action is being performed. I also added this to mk2, not that I like the looks of it, but it might help the colorblind too.
And on the Sync/Quant SooperLooper submode I added feedback on the chosen global Quant setting: when changing, it shows both sync and quant (-:None, C:Cycle, 8: Eighths, L:Loop) settings.
The soft key next to the global, top row (Clip Stop) can be used to inspect sync/quant, and the Soft Key ‘Solo’, below it, can be used to view and change eighths settings without having to press both the up and down pads for eighths simultaneously.
Then: the Gen 1 version has pots instead of endless encoders. And you (I) don’t want values to suddenly jump. Most of this is fixed, but in device mode there may be some screens where they do nothing, as not all screens implement the zynpot_abs() method.
I added two atomic commits adding absolute knobbing to the Tempo (picking up) and Note Range & Transpose (immediate) screens. This could be of benefit to others too. But I refrained from adding it to the Mixer view, being too complex to be easily done. Absolute knobbing with jumping would be easy (for Pots 1-3), but picking up not so. Especially with volume this is necessary.
Maybe someone more knowledgeable could pick this up, also keeping in ming there’s also the Zynbleton development which may render any work done here moot (have to admit I haven’t really checked that out yet).
SO: In Device Mode, Knob#1 to Knob#4 do nothing currently on the Mixer screen, and maybe other, more buried screens where Knob#1 through 4 ought to do something. Resolution most often lies with implementing zynpot_abs() in the appropriate views.
And then there are the in-menu values, such as global transpose. I haven’t found a good way to deal with those yet. It would be nice if the Zynthian system ‘simply’ let the up/down keys perform a single step up down until confirmed/escaped. They do when editing pattern values (cuia “ARROW_UP” and “ARROW_DOWN”), but then also the view is changed.
Where I could not use zynpot_abs() or where it was a SooperLooper value, I implemented picking up by proximity of 1% (as do parameter controls) and then a time window of 0.2 seconds to account for speed dialing.
What I did to to overcome the lack of relative encoders, is on the
Device Mode add a 4x4 matrix (unlit) at the left bottom. This also
helps with stepped/boolean values.
| Knob 1 | Knob 2 | Knob 3 | Knob 4 |
|--------+--------+--------+--------|
| +10 | +10 | +10 | +10 |
|--------+--------+--------+--------|
| +1 | +1 | +1 | +1 |
|--------+--------+--------+--------|
| -1 | -1 | -1 | -1 |
|--------+--------+--------+--------|
| -10 | -10 | -10 | -10 |
|--------+--------+--------+--------|
It takes up a lot of space, so if Oscar one day decides to use these pads, we’ll have to think of something else. Using Shift for the +/-10 values is one thing I thought of.
Last but not least: Akai APC key25 mk2 flipped the position (and MIDI number) for the soft_keys MUTE and_REC_ARM. To port back to the first generation order is a hassle to account for in code. With enough backlash I might do something about it, but I’d rather advise you to put two stickers in place or something. Plus, if you have both devices, such as I do right now, you do not have to retrain your muscle memory.
@oscaracena: I had to tweak your code quite a bit, both in order to subclass the various handlers, and also to abstract away the colors and such, so that the subclasses may assign other colors. And I found an issue in the base driver that not everything was unloaded on unload due to subclassing from two classes. This caused the old instance to keep sending feedback to the leds.
Please review my code carefully, and let further technical stuff be commented in the PR.
