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

Hardware
143

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
144

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.

145

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.

146

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.

147

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.

148

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:

149

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.

4 Likes
150

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:

3 Likes
151

Actually, the encoder buttons still (or again?) do not work. No action is triggered whatever I set for the (encoder) buttons at positions 24-27 (i.e. Switch-21 to 24 in the webconf). If I set the pin numbers to positions 0-23, the buttons DO trigger the corresponding actions.

So, I am still completely lost as to how this actually works.

152

You have pins configured to ignore the first 24 switches then assigned I2C extended pins 0, 3, 8 & 11 to switches 24, 25, 26 & 27 (zero based). I assume you have then assigned CUIA to Switch-21 Action, etc. then activating the switch attached to the I2C GPI extender port 0, the CUIA assigned to Switch-21 Action does not trigger - right?

[Edit] There is a MAX_NUM_ZYNSWITCHES hard coded into zyncoder of 36 (or 52 if zynaptik enabled) but this is below the 28 that you are trying to use.

153

Right. The switches trigger an appropriate action when I put their pin number instead of some -1 on the positions between 0 and 23, but nothing happens on the positions 24-27. (I actually only tried to put the first switch pin number 100 at position 0 - triggering correctly SOLO for current chain - and position 4 - triggering correctly the MENU action.)

I wonder if this is not another effect of the “magical” Wiring layout profile setting - as mentioned above, I have no idea how many things this setting may actually affect. The profile “Custom” did not work for me at all, so now I use the profile “MCP23017 encoders”. Maybe I have to select something else?

154

When you try to use GPI position 24, what CUIA-Action have you configured for Switch 21?

155

The default V5 action, i.e. V5_ZYNPOT_SWITCH 3,S. But I also tried setting MENU, SELECT or POWER_OFF. Nothing happened.

156

But do you have physical switches?
What is your REAL hardware?
You should configure things according to your REAL hardware.
If you don’t have REAL switches, you should use Dummies config, configuring all pins to -1.

Regards

157

Ok. So, let’s make a summary of the ZYNTHIAN_WIRING_SWITCHES configuration:

  • I do not want to use V4 encoders with fixed functions anymore: hence “-1” on positions 0-3
  • I have the 20 buttons from V5 emulated by virtual onscreen touch buttons: hence “-1” on positions 4-23
  • I have four physical encoders wired to MCP23017 (pin assignment from V4, but the MCP is wired to RPi5 exactly as the first MCP in Zynthian V5): hence pin numbers 100,103,108,111 on positions 24-27

The current wiring configuration is thus as follows:

export ZYNTHIAN_WIRING_LAYOUT="MCP23017_ENCODERS"
export ZYNTHIAN_WIRING_ENCODER_A="102,105,110,113"
export ZYNTHIAN_WIRING_ENCODER_B="101,104,109,112"
export ZYNTHIAN_WIRING_SWITCHES="-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,100,103,108,111"
export ZYNTHIAN_WIRING_MCP23017_I2C_ADDRESS="0x20"
export ZYNTHIAN_WIRING_MCP23017_INTA_PIN="0"
export ZYNTHIAN_WIRING_MCP23017_INTB_PIN="2"

Result: rotating encoders works, pushing encoder switches does NOT work in this configuration.

If I set some of the physical pin numbers (e.g. 100) on some of the former positions 0-23 (in place of some of the -1s), it DOES trigger the corresponding action assigned to that switch (i.e. function of a V4 encoder switch on positions 0-3 or of some of the 20 V5 buttons on positions 4-23). However, nothing happens when the physical pin numbers are configured (as listed above) on positions 24-27 (whatever function is assigned to the corresponding “Switch 21-24” in webconf).

I have no idea about the differences between all the different ZYNTHIAN_WIRING_LAYOUT values, but:

  • I tried V5 which does not offer customization, so that everything was broken, including my touchscreen calibration
  • I tried CUSTOM (with the same PIN number configuration as above), but neither rotating the encoders, nor pushing their switches worked
  • I ended up with MCP23017_ENCODERS and so now turning the encoders works, but pushing their switches does NOT work (unless I set them to positions 0-23)

Is there some bug involved or just my misunderstanding of something?

158

Problem found. The number of potential zynswitches in zyncoder needs to be risen on line 104 in zyncontrol_vx.c at least to 28 (if not the full amount of 36?):

#define NUM_ZYNSWITCHES 24
1 Like
159

Hallo @riban ,

Would it be possible to implement the “release” parameter for V5_ZYNPOT_SWITCH as well?

Again, I’m playing with the templates for Open Stage Control in conjunction with the touch screen, and I’m not able to simulate everything.

160

It is there! CUIA V5_ZYNPOT_SWITCH N,R (for zynswitch number N), if I remember correctly…?

(Yeah, I already noticed that in this post above.)

161

The press - release combination works for command /CUIA/ZYNSWITCH but not for command /CUIA/V5_ZYNPOT_SWITCH

zynthian.28
zynthian.281659×595 115 KB

2 Likes
162

OK. Right. I am using just the more low-level ZYNSWITCH which is later mapped to consequently trigger the V5_ZYNPOT_SWITCH actions (S/B/L) according to the push length. Sorry.