Whilst updating a Pi3 on stable.
Oct 15 11:20:33 zynthian-amp startx[489]: gpio: Unable to open GPIO direction interface for pin 7: No such file or directory
Oct 15 11:20:33 zynthian-amp startx[489]: wiringPiISR: unable to open /sys/class/gpio/gpio7/value: No such file or directory
Don’t remember seeing that one before. But it’s about to get a new SSD so it might stop complaining.
Caused by use of a previously working GPIO direct connected Encoders as per :
With wiring selected and above pins it fails to start with above line.
I’ll log a bug.
Caused by spi mode being enabled in raspi-config…
The pin involved was the only pin i’d used in the SPI block GPIO 7,8,9,10,11
D’Oh !
So did you chose different pins or disable SPI? If the latter please share with the class.
Disabled SPI in raspi-config.
Mind you it’s a right old fight as the pi keeps rebooting and you don’t get webconf for more than 10 seconds or so…
Still fighting pin 11 & audio device.
I think this Pi is in for a new stable build.
It’s now working at last …
now that was a bug!! 
Ok.
Rebuilt on a clean stable…
Configured.
Wouldn’t start.
Updated.
Switched to testing.
Added audio card hifiberry Amp…
Started . . .
Configured wiring as per attached … Same problem …
Turned off SPI in raspi-config now works . . .
So there is something about the hifiberry amp settings and the SPI mechanism…
After a bit of soldering …
Moving the Prviously pin 26, connected to the Back switch to Pin 10 and including 16 in the 2nd position of the Switch settings, we have a functioning zynthi…
And it reboots cleanly!
I notice we have the timeout power off back !! Nice.
updated zynthian-alm.local
25,26,4,0
27,21,3,7
23,16,2,22
I’m currently experimenting with direct wiring now - I was having trouble figuring out zynseq and sooperlooper yesterday and I’m wondering if my Teensy stuff is working-but-not-really and that’s why nothing seems to be doing what I think the reading says it should do. Anyways, I’m getting this same Pin 7 error, I also am about to try disabling spi in raspi-config. Will report.
I was initially using GPIO7 (pin 26) for one of my thingies but I moved it to GPIO17, but the pin 7 error is still there.
edits:
Disabled SPI in raspi-config and it boots to UI, but the encoders are not encoding.
It’s rather unhappy about something, dmesg is just spitting out a bunch of these:
[ 25.055806] i2c-bcm2835 3f804000.i2c: i2c transfer timed out
googled and apparently this happens with pi3/pi4 differences. As it happens, this unit is running on a Pi3 because I only have one Pi4 and this unit is for the piano player. Swapping in my Pi4 to see if that fixes it.
Has the same problem on Pi4. Re-enabled SPI, Pin7 problem has returned. On stable at the moment, wyleu switched to testing above, I suppose I’ll try that and then turn off spi again, just for fun…
The CUIA code is getting a severe kicking at the moment, which from our perspective is a very good thing. I’m pretty sye bold and long back on the backspace key isn’t working at the moment over CUIA and I know others know this.
So perhaps hold fire and entrench the components that do work. I’ve spent many, many hours waggling both the tail and the dog in such situations and it requires a consistency of view to make progress. But you do get a very good overall appraisal of the system…
Never did get to the bottom of this one. I was just content I got a previously functioning device back.
I’ve built a few I/o pin encoder rigs but have contented myself since Pi4 with controls over 12c, MIDI or Qwerty.
You, have at least, ruled out hardware issues which is generally my first suspicion on changes like this.
Especially if the last thing you had in your hand was a soldering iron…
That looses you many hours.
Have we seen pictures of the teensy device?
Had a little play with CharGPT on this GPIO issue but no insight.
I uploaded a tiny video of the knobs twiddling, that’s it so far. What inspired/annoyed me enough to pull out the Teensy and start fiddling with direct wiring (currently have tabs open with aliexpress pages to the mcp devices for future use - I also have some primitive multiplexers on the way) was that my encoder handling ended up doing nothing for one detente when reverse direction (so when you’re going in one direction, you have to twice in the opposite direction before the param starts changing), and also awkward to use for the full range of midi paramaters without adding some acceleration in there, and while I…
I just gave myself pause, because I instinctively said to myself “Instead of learning how to implement acceleration in a rotary encoder, let’s see if we can just wire it in direct without the MCP device since I’m using an HDMI display and let them handle this the way they intended,” but in this moment in time, I’m kinda thinking that wrapping my head around knob-turn-acceleration algebra is probably a very useful thing to use my time for. I enjoy making cartoons, but I would quite honestly rather jump into the digital instrument industry in some fashion. There’s also probably a library. I should’ve stayed in school, learning math in your 50s is not for wimps.
My current situation, I can’t remember if I’ve talked about it here yet but my local hackerspace has an annual festival weekend after this coming one called Hax, and I’m gonna be doing a live talk/demo of building a headless Zynthian (“if you have a pi and any USB sound card, you can have a pro-grade synthesizer over vnc!”). I am still quite covid-shy so I’m doing it remote, unless they enforce masks, which I’m quite certain they aren’t doing. The talk will be streamed live to the internet, I believe, so yall can tune in if you want, it’s April 1 at 10am CST. Hax Festival Event Page Link Here
The Zynthian in its current form will be on display at the festival, and setup for people to make some bleeps and bloops on it through the day (I have smart people who can bring it back up if someone actually manages to crash it, we might limit them to using the sliders and buttons on my cheap midi keyboard controller).
What I would like to do is setup rtp-midi, and do all my live demos of the sounds by playing my keyboard onscreen. and having the sound come out of their local device in front of them - I think it’s TedTalk-level showmanship, IF it works over that long a link. Uniform latency is fine, I won’t be there to hear the output, but if the note timing gets scrambled it’ll be more like a TommyWiseauTalk, so it remains to be seen whether this will happen.
I theoretically have ssh access to their local network, to be tested and verified, so it should be quite simple to setup a tunnel. My first step is to get two zynthians stood up this weekend and demonstrate to myself that it works as well as you folks say on the local network. If it does, the attempt will definitely be made to do it over the internet. Probably I’ll set it up at the piano player’s house and get them to listen to what comes out, in theory that should have just as much lag as going all the way to the city, I’m on starlink.
My plan is to put together a Youtube video ahead of time which contains all of the content of the talk - especially the parts where you can encounter delays of many hours, such as when your SD card reader dies on you and it’s already your backup cause the other one died six months ago and you had to go into your local tiny town and find the ONE reader in town, which thankfully works, and came as a bonus with a 32GB card, which brings me up to three SD cards big enough for Zynthian lol. It’s also a USB-C reader, I just used USB-C to write an SD for the first time and it was about four times as fast. Nice. Hope my one machine with USB-C lives a good long life cause new PC is a long way off. The reader does regular usb too but C is nice. :>
So yah, I wanna have all the visual aspects of the presentation queued up to go on video with no minutes-eating glitches. I’ve played with OBS a bit and I might try to draft a friend of mine with an HDMI switchbox to produce for me, make it a one-hour show. I tend to get a bit nuts once I start a thing.
But as a baseline, I am prepared to just plug the Teensy back in, point a camera at me and the box, and wing it. I have fronted many bands and I can keep people reasonably amused even if the technical aspects go all to hell. I basically soldered all the connections for the encs and four switches onto a protoboard with a couple of sockets that match up to the teensy pins, so I can bring it back to that point with zero effort. Then I did the same thing on the pi end, just a bunch of dangling stripped wires at the moment that are shoved into the Teensy sockets.
I shot video of the guts and a better document of the build will appear eventually, when the build is finished lol. I’m giving myself till Saturday to see if I can make the direct wiring work, if not we’ll go with Teensy for the moment and I’ll revisit once I’ve gotten some MCP boards. I also might explore duplicating the MCP’s i2c message and just sending them from an arduino, I haven’t figured out how hard that is, there might be a library out there that does it, who knows.
Maybe the devs can give me the important technical details for substituting an arduino for an MCP, doesn’t need to be extreme handholding at this point, I’m pretty good at figuring stuff out, as long as what I’m figuring out is actually possible. My big problem is I’m always trying to do stuff that isn’t possible. But I’ve got many arduino-type devices that are begging to be used, they talk to pins and they talk to i2c, seems like an easy one. But I guess I would need to know what the zynthian expects to hear over the i2c bus and when, and as long as the description contains nomenclature that I can google and connect to arduino concepts, I’m laughing.
So that’s the state of play at the moment. Work starts soon, further progress will be made tomorrow morning I’m sure, and we’ll see if Joe notices this thread.
One of the great software evolutions was Perl to Python and the basic mantra was one of experience. The many ways to do it approach of Perl involved massive degrees of reinventing the wheel. Python gave us this is only one way… Use the libraries …
Tim Peters wrote a marvelous article about writing sort routines, which he most certainly did, and I’ve avoided writing sorts when I can use the python sort facilities. It’s progress.
Worth going if you can. It refines your live kit, and your relationship with it. It also teaches you that with self built stuff the re is one critical lead that you must have with specific connectors on the end.
You will learn two things
1/ You ALWAYS forget one object.
2/ It’s always the critical one.
It sounds marvellous!
Problem being, I’m coding in C :>
I’m sure there’s still a library though. There’s just so many different ways to play with these things, that’s the hardest part.
You could practice into zynthclub I imagine.
So yah, can confirm, the error only happens when I attempt to enable directly wired stuff, I switched back to Dummies and it started up fine.
I have everything I did written down in the form of a very messy sheet of paper with pencil on it, so I dunno if I’ll bother documenting everything here. Unless there is a will to try to figure this error out as a team, but being this is very nonstandard, I have no such expectations. I do expect them to have to have those V5 kits ready, pronto. But that’s as far as my sense of entitlement goes. :>
Well I’ve transported the code as far as the MKRZERO and the pin mapping works!
Bounce button[buttonCnt] = { Bounce()}; was the magic incantation. Don’t know why…
Now just to add a MIDI library I can get working or keyboard mappings…
It did occur to me yesterday… this code could just as easily - easier, actually - be a keyboard as a USBmidi. :>
I’m expecting some cheap multiplexers any day now from China, I’m gonna have a go at implementing Riban’s i2c hwc code next, which is more or less what I had in mind when I first thought of this approach. If I can wrap my head around that, I’ll have a huge pile of available hardware expanders.
I will modify the code to provide a qwerty solution so we have a rig that can test the interface, across both mechanisms.
I also have one these from when I was teaching myself animation (my job title is Technical Director, it actually means AnimationSpecialized_Python_Coder(Coder) and in order to be good at it I pushed myself through all the standard training for users of Blender) - I figure it will adapt pretty good to the V5 interface :>
I’m developing an intense dislike of QWERTY keyboards…
It mostly works but it’s horrid.
It does at least demonstrate a working device, but things with long press’s seem a little chaotic.
