DIY: upgrading to V5 - or the question of new buttons

A little history might help.

The first version of zynthian had a combination of an external chip to handle some of the encoder pins and then used RPi GPIO pin for others. this produced the GPIO settings which were a low integer including zero that matched the pins chosen. I don’t know why it was done that way, perhaps @jofe remembers…

People quickly moved on to pure GPIO pins which worked quite well and is heavily documented in the pre dawn history of this forum.

The move to an i2c based MCP23017 came in with a desire to simplify the process and use far less pins on the Pi. and allow extra connections like the A to D and D to A pins and i/0 switches, where we would have simply run out of available pins. This also figured because the Pi itself doesn’t have any analog ins or outs among its GPIO connector which means something had to be constructed for this. and so the addressing number moved into the hundreds as a mechanism to make the interfaces consistent.

1 Like

Yes, I can guess that. But the configuration is just illusional unless you select the proper “wiring layout”. Selecting the “Mcp23017 encoders” works, but “Custom” doesn’t work. Still, both “layouts” offer the same configuration options.

The “wiring layouts” and their cryptic names have allways been a mystery to me. Now I have traced them in the sources and it seems a lot of behaviour is just hardwired to their names, whatever the additional settings are. The “V5” seems to be an extreme: not only it does not offer any customization, but it goes as far as breaking the touchscreen calibration. I do not dare to file it as an issue (as @riban suggested), because it looks more like a feature than a bug.

But “layouts” that offer customization and yet have no effect at all (e.g “Custom”) seem far worse to me.

I work from Custom. It’s the one chunk of data I screenshot for every zynth I have.

The wiring layouts are, as you say, the early days of config but start to take on relevance once you use mechanisms like zynaptik cards. In the GPIO world it’s a bit more agricultural.
It all functions but the real lack is probably tightly linked Documentation to instill confidence in the process.

Doing docs of this sort needs careful confirmation to ensure they are acurate, but might best be addressed when oram is stable so we know we are documenting a declared starting point.

Strange why it did not work for me. Or do you have everything wired directly to the GPIOs? So that “Custom” would only work with direct GPIO numbers while the “Mcp23017 xxxx” profiles would (only?) work with MCP PIN numbers? Nevertheless, @jofemodo lately reported it should now be possible to combine both (but didn’t specify how, yet).

Right. Some documentation would be definitely useful, but needs checking all the details in the code (or memory of the authors), as you say. Even better would be a proper cleanup, but backward compatibility is a burden and there are also far more important priorities just now - finishing Oram and all the strange issues with various Pi5 versions.

In truth Iv’e never found it to be a problem. Hardware issues can be a right royal pain, and you need decent measurement kit like oscilloscopes to be really sure. Have you changed the chip itself?

I have devices that are entirely built around GPIO pins and added some RGB LED’s for good measure so I’m pretty relaxed about that, but I wouldn’t do it now. It’s just too inflexible.
Most of my development in these direction would be using a Blue Pill and chat to the zynth using a MIDI or Qwerty protocol. But I’m doing different things from most in this regard and it has it’s issues as well.

I’ve not breadboard built a MCP23017 based device, all mine are on zynaptiks boards but there isn’t an obvious magic element.

I spent hours checking that the wiring and MCP are OK. And the PIN settings. Only to find out the only problem is the “magical” zynthian setting called “wiring layout”.

I also started a project of a whole control panel with 12 pots, 12 encoders, 24 switches with LEDs and 3 OLED displays - the plan has been to use OSC (or MIDI as a fallback) to control zynthian or other devices and eventually even get feedback and report it on the displays, if possible. But I somehow lost my patience when I found out that I underestimated many things. Surprisingly, I somehow managed the basic mechanical design despite my lack of skills in craftsmanship and was trapped in wiring/software issues, where I had originally felt much more confident. So, it has been lying there unfinished since, waiting for me to get some courage again… :slight_smile:

Added Pull Request #501 with my current implementation of the touch keypad. I have also merged latest changes done meanwhile in the upstream. We can create an issue on GitHub to continue discussion about technical details of the implementation, if not suitable to discuss here.


PR #501: Added support for wsled brightness, so now the “brightness” of the button labels can be adjusted using the UI brightness settings, separately from the general display brightness. Of course, this just means dimming the colours.

Unfortunately, tkinter toolkit does not seem to support alpha channel in colours, so that it requires computing a blend of the foreground and background colour :confused: