I have built a DIY Zynthian. I have used in sinse 2020. I had no issues whatsoever.
The only complaint I had in an older Zynthian version is that MIDI recorder was very slow. After hitting record I had to wait for 10-15 seconds. And that’s on Raspverry Pi 4 version B.
A few weeks ago I got myself a new SD card and installed a new version of Zynthian.
There was no hardware modifications, the only difference is the version of Zynthian.
Now when I press CTRL-2 (back) button I get to Mixer, so all is working correctly.
But, in a few seconds Admin window opens just by itself.
Also, when I click other control button sometimes CTRL-4 (select) long press false triggers and I’m getting Turn Off dialogue.
I have tested with oscilloscope and there’s no false trigger on the encoder contacts. There’s no voltage spikes. I’ve checked and rechecked all the wiring, and as I said before there was no HW modifications to my build. So the difference is in Zynthian soft.
My build is simple and all encoders and switches go directly to raspberry Pi 4 header. I do not use MCP23017.
As for the sound output I use a cheap pcm5102 board, configured as Hifiberry dac + Light.
Encoder A: 25,0,4,22
Encoder B: 27,7,3,21
I wonder if any of those pins are just not suitable in the latest update and are used for something else.
Any ideas or suggestions would be appreciated greatly!
I would hate to go back to previos Zynthian version, as I love the features in the latest version.
I have the same problem with the new software. I had so many accidental switch off and switch to Multitimbral Mode (I press the Select anywhere else but the Turn off or the Admin appears just before the press) that I connected a mouse and a keyboard instead.
Similar hardware, encoders connected direct to gpio. I have KY-040 encoder moduls, 3.3v connected - the experts say here this isn’t the best, but it was very easy, and worked until now. Hifiberry DAC+ ADC soundcard here.
Hi! Thanks for confirming this issue! I’ll try using MCP chip, but that’s in the mail and will take some time before I try it.
Thanks for raising a ticket. I am away for a few more weeks so don’t have access to a device on which to test this specific confirmation.
Like @riban , i’m not at home and have no access to hardware to test. I have tested the last stable in v1 zynthians, what are directly connected to RBPi pins, and it worked flawlessly.
Anyway, the encoder code has been deeply refactored and things work quite differently now, so perhaps your encoders are not working OK, specially if they didn’t have debouncing capacitors. I strongly recommend to have 10uF on each encoder pin, and 100uF capacitors for switches.
Thanks @jofemodo . Would the Basic Kit v4 be the real solution?
It seems like the release is not being captured and the presses are being managed like long presses. I’ve tested the new code with bare encoders with debouncing capacitors and they work nicely, anyway, i will test again and will try to reproduce your issue. @riban, perhaps we should scale the priority for implementing a proper event queue instead of the direct call approach we are using currently. Do you remember our talk?
I remember everything… eventually!
Got MCP23017 as I was hitting a wall with my encoders soldered to GPIO. Even though I had those debouncing caps soldered in, the value of caps were correct. So by soldered encoders to MCP23017 I resolved my issue.
I’m not a big advocate of using the GPIO pins . . .