So close! Usb interface help please?

I have a Tascam US 4x4 - the four channel version, and it works well including MIDI.
To enter the configuration you have to use the “Generic USB device” Soundcard, click on “Advanced view” and put the following into the JackD Options field (yours will probably listed as US2x2):
-P 70 -t 2000 -s -d alsa -d hw:US4x4 -r 48000 -p 256 -n 3 -X raw


stuff that config in a bug and we’ll make you’re own menu item for you and your fame will last forever!

1 Like

This community is excellent :grinning: :face_with_monocle:

I’ll be uploading some progress media soon! It’s been months of research, and a wildly exceeded prototyping budget :sweat_smile: , but this baby eldritch beast is expected to born, and presented to its new master sometime this week! Can’t express enough gratitude for the zynthian community and developers for having such a beautiful vision and following it through. Music to the masses!!!

P.s. woof, chips are getting scarce and pricey

Hello Friends,

I’ve got my circuits planned for the 4 rotary encoders, and 4 push switches. And they should be all soldered together tonight and tomorrow. I’ve got all the pi 4’s GPIO pins avaailable; as the screen’s display is thru hdmi and it’s touch, audio output and input, and midi are all running off usb.

Is it fairly straightforward in webconf to assign the 4 encoders, and 4 momentary switches(the ones attached to zynscreen in the current Official Kit) to gpio ports? I saw that support wass added in webconf to set up extra switches, and I’m hoping that the same area can set up these not extra switches and encoders.

Also, is there a functional limit to how many things can share a ground on a circuit? Someone in a thread I can’t find here mentioned they connected some encoders they got off amazon to separate ground pins on the pi. But it that entirely necessary? As I understand it the ground pins on the pin are a single ground circuit.

Thank you again for the help! :face_with_monocle: Home stretch!

1 Like

Lol, I’ve been so hyperfocused on this project, I only just noticed what you meant by the monocle face @wyleu :sweat_smile:. I just read your reply, but popped back to ordering a few last cosmetic bits. I thought one uses it to express gratitude. You were saying I should post some media :sweat_smile:. No worries much media is coming :relaxed:


Stuck at work, but the research continues! Gonna drop the resources I’m finding here. Both so I can find them when I’m off, and for anyone else who stumbles on this post searching for truth.

Wired up some encoders but got stumped when I saw the pin values in webconf. Then I stumbled on more wonderful work by @wyleu. Believe this is the answer to what pin numberings to use when setting up encoders and buttons in webconf:

What does one do to discover what jackd options would correspond to a usb audio interface? I’ve gotten the system up and running on a behringer umc204hd by using the preset for the umc404hd in webocnf, but can’t get midi on that interface to come in(haven’t tested out yet). The used steinberg ur22 mkII I found isn’t being recognized with the ur22 mkII preset in webconf. @catherder how did you grock the settings you’re using for the tascam us4x4? Unfortunately they aren’t working for me on the us 2x2 (even with changing the name in jackd options to match the different model)

If I know where to look for such identifying info on an interface, I’m hoping I can unlock midi on the 204HD, or get it all working on the 2x2 or ur22. If I can’t get those working I might have to cobble together a midi board and use one of the two behringers that are making noise.

Thank you again for any help you can provide

Somewhat an offtopic and probably not worth it for this project, but one non-obvious benefit of using Pipewire (Pipewire (built from source, not from RPi repo)) is that it discovers all devices itself, so no need to bother with jackd command line (nor try to fix the boot loop if the USB interface is disconnected).

Pipewire does look interesting. Unfortunately I’m working to get this thing up and running in a few days. It’s for my partner’s birthday gift, just before they’ll be moving away for a few months. If it weren’t for concern over lead times, I’d have just ordered an official kit. So many people have reported success that I know there’s got to be a way to get everything running on one of these usb audio interfaces with midi that I have now. Anyone have any tips on how I can find what information needs to be in jackd? Zynth boot loops on the tascam us2x2, and steinberg ur22MKII, with the default and suggested webconf settings. It’s boots great on the umc204hd and uca202(using umc404hd and uca222 webconf defaults). But uca202 does not have midi, and I can’t seem to get anything in or out(finally tried out) of the midi ports on the UMC404hd.

Sorry this may be a very noob question. I’ve got an alright handle on the circuitry, but the code side of things is still fresh for me and essentially a foreign language. Thanks again for any elucidation that can be offered

Using a Behringer 1820 the Midi just functioned. It’s not related to the audio settings, bu I suggest a look in the Webconf MIDI settings, just to see what the zynth believes is visible.
aconnect - l


on the zynth command line will reveal what devices are available in the Midi alsa world and by extention what is available to jack.

and pressing the plus symbol (+)

The audio settings are derived from
aplay - l
in a similar way. The command line values are parameters for jackd and are defined in Jack’s not particularly helpful documentation. The most important thing to realise is that the default behaviour selects devices by number and these can change on startup or devices present or sometimes just the colour of the last car that past, so it’s really the name you need for webconf as this sets the link emphatically. The rest are rate settings or similar.

Pipewire is certainly of interest, because it looks like a component that will break throu the one audio device limit that are imposed at the moment. I posted a thread with one of my normally evasive experiments using a USB 1/4" jack to USB and a hifiberry card but the two clocks drifted and clicks occurred, so that’s as far as it directly went, but we’ve certainly discussed it informally.

So I suggest you use the command line to ensure the MIDI port is detected because without that you might have a broken midi port, and if that’s not the case make sure it’s seen by alsa and then progress with patchage and Jack commands to see what you can and can’t see.

Hope this helps.

1 Like

Thank you @wyleu! I got no where with my efforts last night, but this sounds like the info I need. Gonna give it a try now :grin:

Hello friends!

Fresh new hell :sweat_smile:. If y’all help me fix it, I’ll upload some sick audio :blush:. I’m seeing info all over the place, but it’s not terribly organized. Has anything changed about what pin numbering the wiring in webconf uses?

The link I put above on connecting encoders directly to the gpio, seems to answer the question. Yet I’m getting no response from the zynthian system. I see people have gone round and round explaining the encoder breakout boards you can get on amazon and aliexpress. I opted to use unboarded encoders. To the best of my knowledge the use the standard encoder pinout.

If they don’t use some uncommon pinout then looking at the bottom of the encoder, with three prongs on right and two on left, going clockwise starting at roughly 1’oclock on a clock face, they would be: pin A, cnt grnd, pin b, switch ground, and switch.

But using wpi pin numbers in webconf is giving me nothing. I haven’t tried to make a debouncing circuit, just hooking them directly to gpio. I’ve tried putting them wherever feels convenient, and I’ve tried putting them where I can see others have put them in their webconf screenshots. But I’m getting nothing. That’s what makes me wonder if maybe the pin numbering convention was changed in a release between the forum posts I’m seeing(mostly late last year) and now.

Or is it possible I’ve got a whole set of 10 bad encoders? It was amazon, and no one can really speak for their merchants quality control. I saw some where that you can only daisy chain about 4 encoders to a ground. Is that a thing? I haven’t actually hooked all 4 encoders up at the same time(experimenting with different connection types left me with less socket to plug jumpers). Have some good wire and a terminal breakout arriving today that will let me rig them all up at once, waaaaaayyyyyy easier than I was doing it.

Do all the encoders need to be connected simultaneously for any of them to work? That could be another reason that mine isn’t working. Do to having only 6 socket to plug jumpers I could only try one at a time on breadboard. When I did this I used x,none,none,none in the pin a, pin b, and switch fields, where x is the wpi pin number that I’ve connected the encoder pin to. tried running switch gnd thru center gnd, and running it to it’s own ground pin, with no luck. As I understand, the gpio pins supply 3v so there’s no need to hook the encoder to a 3v3 or 5v powerline(heard 5v can fry the pi) So if for some reason the encoders only function in zynthian when all 4 are connected, then that would explain why I can’t get anything to come up for the encoders I’m programming. Wouldn’t make sense to me, but most things don’t until they do.

Also, for any future zynthisists out there: Webconf does not ask to reboot when new wiring is saved, it just reboots. Don’t hit save again in webconf, before it reboots. Expecting the prompt to reboot, I hit save again thinking webconf didn’t hear my mouse click. If zynthian is rebooting and you hit save on wiring in webconf, it will corrupt the zynthian image and you’ll need to flash a new sd card.

Any help with this wiring nightmare would be greatly appreciated. It seems preposterous, but not impossible that all 10 encoders I ordered are bonk, and I tried so many ways of hooking them up(breadboarded, fully soldered, soldered encoder to breadboard to pi). So unless all the various solder joints and breadboard connections are failing, it seems like there has to have been a change in how the zynthian wiring in webconf works between now and the last slurry of this question being answered.

You’re all bad asses, and I really appreciate your work. I know it’s got to be frustrating to reteach every new generation, and that’s probably where some of the “your answer is somewhere on the forum, go look for it” responses come from. But a lot of the people finding answers sort of drop off posting once they figure it out, leaving weird info gaps all over the place. If any of you actually geniuses could provide clarity, or clarifying links, then maybe we can compile these fixes here, and then maybe transfer them to official documentation. Plus, again, I will reward you with some tasty bass riffs my fingers and zynth keep coming up with :blush::face_with_monocle:

Thank you again


I don’t think anything has changed.

The three pins are the encoder with common in the centre. The two pins are switch which can be wired either way.

There is sometimes a capacitor on encoder PCBs to act as a filter but this is not necessarily required and generally reduces risk of false triggers, i.e. is not required to get the thing working (or at least partially working).

Pretty unlikely. I have never had any completely broken encoders and I have bought a lot of cheap units.

That is more of someone’s rule of thumb. It depends on the wires used, the quality of the ground, the routing of the wires, etc. At these currents and these speeds I would expect you to be able to use a single common ground pin for all connections.

No, they do not but you do need to configure them all in webconf.

I think this is most likely your issue. Assign valid and free GPI for all four switches and all four encoders. I seem to remember (not checked the code today) that there is a constraint that partial configuration is not acceptable.

Indeed! The encoders and switches act as switches between the GPI pin and ground reference. The GPI is held high by internal resistors and when the switch closes it pulls the GPI low which is detected by code running on the Raspberry Pi. (Encoders are just two switches that open and close in a particular pattern.)

Please report this as an issue.

This is more of hacker info. The official kit should just work and should be properly documented in the official documentation. The forum is a good place to ask, answer and search for info on non-standard builds like this. It can be a haystack with you not knowing if that precious needle of info is in there so it is good if questions and answers are clear, unambiguous, fully descriptive and ideally, edited for accuracy.

I would suggest you configure the hardware in webconf for all the GPIs for the 4 switches and encoders then try just one switch first, e.g. BACK switch. This should allow you to see that the simplest action is working. If not you can diagnose that simple issue. If it is then you can start to add more switches and encoders, diagnosing issues as they arise without trying to boil the ocean!

Good luck.

Thank you. I think that confirms what I was wondering. That if the encoders aren’t set in webconf it could cause a problem. Several of the attempts were done with the wiring from others screenshots, and pre-existing wiring profiles in webconf( emulator I think was the only one that starts out with values all under 100). By which I mean I left the other wpi pin numbers in webconf, and just edited the 1st one in each field to match the gpio pins the encoder was connected to. So, in theory, my switches or encoder turns should have worked on one of those tests. But still nothing. I’ll be trying again this afternoon tho, so fingers crossed.

Thank you again

Maybe a picture of the wiring might help and a screenshot of the configuration. One can sometimes identify something that has not been mentioned by looking over someone’s shoulder.

I think @wyleu has (recently?) configured a Zynthian using just GPI so may be able to give you a screenshot of a working configuration.

Remember there should be 4 integer numbers separated by a comma in each of the “Encoders A-pins”, “Encoders B-pins” and “Switches Pins” fields. There can be more integers in the switch pins which enables extra switches like the 4 at the bottom of the screen on the official V4 kit.

1 Like

AAh yes the glorious world of zynthian encoder config…

I have to relearn it everytime I REALLY muck around!

A bit of history helps.

The Zynthian started out on the standard GPIO pins and, indeed you can build the original 4 encoder zynth with nothing more than a gpio connector and … 4 encoders.

But which pin on which encoder goes to which pin on the GPIO pins…? Do they all work …? how do I work out what goes where.

Well A Build with Variations variation: HiFiBerry Amp+ goes some of the way to describe the process, and

Encoder mapping for Direct I/O connection - #9 by wyleu shows the mapping in a nice chart . . . .


The Wpi pins match the numbers that go in the Zynthian webconf, so you can use this chart to allocate appropriately. The SPI errors listed are something hat just seems to have magically occured so avoid those pins and ignore the rgb encoders that was a fanciful bit of playing around, that never made it to zynthian code.

Basically you specify the GPIO pins connected to the encoders on the top two rows and the switch on the bottom row…

The encoders are ordered anti clock wise from the top Left…

So the

  1. first column are the Layer ( TL)
  2. second column Back (BL)
  3. third column Select ( BR)
  4. fourth column Learn (TR)

This is all very much he open source way of doing things. To properly support a zynhian infrastructure you can use a zynthian all in one board which does this over 12c bus, and then you will load up the settings in the webconf for that configuration which include numbers in the 100’s

IT may not seen particularly user friendly but it allows us to provide the same interface from similar devices delivered and presented in a zynthian like way.
The Offical kit does this all on the screen board so doesn’t need to support the flexibilities of a homebuild.

Looking forward to the :face_with_monocle: The pictures of the installation often helps!

1 Like

Well last night was crazy, and I only had time to check a couple pin configurations on the new terminal hat before I conked out. Tried with my soldered encoders, and just in case I bonked the soldering, I plugged a few into jst connectors and ran their open wires into the terminal hat. Then I fell asleep. Pics will have to wait till tomorrow, but I’m kind of wondering if my pi’s gpio is shot. I don’t know how common that is, but everything else seems to work fine. Then here at work it occurred to me an easy trouble shooting question for that possibility.

I know people have used gpio for encoders, and that it was the go to on old versions of the zynth. But, does anyone, maybe @wyleu, have a zynthian running the current stable image with gpio connected encoders? If so, then I’ll at least know that it isn’t an os problem, and I can put gpio trouble shooting on the list. Luckily I have a spare pi 4 I can try once I’m off.

I’ve no idea where I’d begin to fuss with or troubleshoot the actual code. But I’ve got some mpc23017s, so I suppose I could also try to mock together an allinone circuit. Logic being if my 2nd pi4’s gpio also doesn’t work, and it gets confirmed that people’s gpio encoder zynths are running an old image, then an allinone circuit does work, it would help confirm that something is happening in code.

Please let me know if that’s a crazy theory. Not knowing fully how the code translates to the digital/physical functions, maybe the fact that allinones and zynscreens work negates the possibility that the current stable of zynthian is fighting direct gpio. If so then that can be added to the tapestry of my logics and help me make better diagnoses in the future.

Thank you!

It’s not an os problem.

Encoder/GPIO Works with stable. I have two machines running this way.
Zynthian-amp.local A hifiberry 60W Amp Pi3 combi …

as detailed here.

The other is zynthian-alm.local which is audio injector card based machine. IT’s wired slightly differently, ( one pin is on a different i/o pin. )

It’s really down to the internal layout of your encoder and Pi combination. That’s how I chose the pins to minimize the crossing over and general wiring mess. With stable avoid the SPI allocated pins.

It’s perfectly possible to run just encoders or switches by appropriate settings in webconf. IT makes for a good test to just see the response from the switches because a miswire produces a very confused encoder response as the button gets pressed by an encoder twist by mistake.

Perfect thank you @wyleu. Wasn’t sure if any of the direct gpio instances out there were running the current stable. Most of those threads are pretty old.

Is gpio readall live, or just a snapshot? If it’s live, and a miswired encoder would cause it to look “confused”, then that’s unfortunately another indicator that my pi may simply not be able to use it’s gpio. When using gpio readall the last couple times it appears static, and the values don’t change regardless of whether I run it again with the encoder unplugged, and/or am twisting/pressing the encoders

I am aware of PI’s with dead GPIO pins, but I haven’t encountered it directly myself. It seems to be people putting 5v’s into the pins rather than 3.3v and its’ irreversible as far as I’m aware.

It’s just a snapshot. You need to be methodical in these situations. if you have connectors then you can swap known working encoders with others and narrow down where the fault or indeed faults exist.

A picture would help even if it’s just a ratsnest on a desktop at the moment.