Having seen the discussions of sound library ownership and licensing the arduinos new owners dont exactly fill some people with confidence.
I am certainly working on replacing Mcp23017 implementations with microcontrollers,even thoubi have a draw of 23017’s
One of the characteristics that aids development is a slick hardware environment and what with st link the Arduino world can involve a lot of opening and plugging to switch between development and use. For instance whilst using blue pill i ended adding a separate debug connector so that i didn’t have to dissemble the device to allow me to update.
But,quite how the hardware is done is really an aspect that we can all decide for itself.
The real considerations are do we implement with i2c,midi,qwerty or OSC? Or indeed offer all as options? and how do we standardise the two way flow of information so that an LED on the device can behave in precisely the same fashion as a led indicator in an lv2 screen of a chain,and two or more way operation works seamlessly?
Personally I’m gravitated away from the simplicity of MIDI sysex towards osc solutions, and am actively replacing blue pill devices of which i have a few with pico devices,because i get circuit or micropython and pio state machines rather than a C based infrastructure. I’m an average python coder and as such can make more development progress in a day with poor python and ai assistance than a couple of weeks of attempting appallingly bad C.
Obviously these are personal failings and no basis for imposing community stricture, but luckily this project allows several creeds to live along side each other.
Rather than looking at semiconductor hardware i m devoting much time to how to do rgb led momentary switches as is done on the V5.
Expect to see an RGB i2c encoder equivalent of a switch and encoder box at some point soon, and don’t feel above nagging if it doesn’t appear.
I very nearly had to cancel a wedding gig because I couldn’t get wifi access for a zynth on a very protected network. I ended up building my own sub network using tethering and a mobile phone and the happy couple got their backing tracks and the violinist got to do her thing…
Not sure this is a security problem that a string quartet has. One doesn’t need to log into a cello.
I would like to see a standard used to interface to microcontrollers over I2C. This is how I wrote my first hardware controller for zynthian and we can leverage that code / approach. I see such a standard having such operations as:
Switch action (switch, action type)
Encoder action (encoder, +/- value)
LED (state (off, on, flashing, etc.), colour 1, colour 2)
Firmware upload (blob)
Firmware version
Such an interface would allow users to implement a compatible interface using which ever MCU they had to hand and the firmware upload option may allow it to be fullin integreated to the core design.
I too have no MCP23xxx but have lots of MCUs of different types. I tend to chose a MCU with max GPI to allow max interfacing, hence my choice of STM32 (as well as its low cost) but the Pico has 25 GPI. Use 2 for I2C and 1 for interrupt and maybe 1 for WS281X LEDs and that leaves 21 GPI per Pico which exceeds the 16 of a MCP23017. You also have some ADC and PWM available.
I have done this for zynthian (although I no longer find the code in our codebase) and have used CAN for riban modular but I don’t think we need that extra level of complexity or robustness as we are talking about internal devices.
A Blue Pill will power LED strips from GPIO pin directly, whilst a Pi Pico likes a diode in line to drop the voltage of supply just enough to cross the threshold. Other wise the Bugera pedal transited from Blue Pill to Pico in an afternoon… ( Someone is beginning to sound a bit like a fan boy ain’t he..? I’ll give myself more soup . . . )
The Grey switch loops thru’ the other pages, Red page 1, Green Page 2 etc The Menu Led flashes every second to tell me it’s alive.
The other five switches can, on each page, be configured for
Momentary (single LED on, both on when pressed)
Toggle (Both LEDs on or off) operation
Nothing NO LED’s → not configured.
. And hopefully will label the functions on the Zynth GUI.
While we’re at it, can we dream of a default decoupled UI that works over OSC? Enabling any tablet or phone for rapid control of headless Zynthian without VNC overhead, maybe even as aapp or web app launched from webconf?
I know the OSC commands already allow all or most of this, just the UI isn’t there out of the box.
It would be really nice to have the engines GUI screen on the second HDMI or second DSI, instead of going through VNC overhead.
This could even be easily added to a V5.1 kit, by notching out a bit of the case (or bending an edge near the corner) and let the cable of a MicroHDMI to HDMI pigtail through. So there is really no point against making this possible!
I think we’re about the same as far as coding skill, but I will say, there is an excellent Arduino library for midi. When I use that name, I mostly refer to the ecosystem of libraries that handle all manner of motors, LEDs, sensors, etc, rather than the branded devices. Teensy and ESP32 can be programmed in that environment by installing an addon to the arduino IDE, and from there, a lot of people can indeed custom build the control panel of their dreams, more or less, if they’re willing to invest a weekend of work, or indeed, a few AI tokens.
I have always predicted that LLMs will be great at task-level coding. I… judge, but I also acknowledge the utility.
I support LLM usage that doesn’t involve making yourself quite literally into the “This Is Fine” meme. IE. runs on your local hardware, not some datacentre that is killing crops and turning tap water brown somewhere in the midwest USA. This is quite a realistic goal. No more difficult than cloning Super Mario Bros on a C64.
Some time ago, there were production managers in the automotive industry who saw it exactly that way. As a result, production volume took precedence over security. This, in turn, led to poorly patched, outdated production computers bringing entire global corporate networks to a standstill.
The moral of the story? If you can implement security measures at a reasonable cost, you’d better do it before the lack of these measures results in a disproportionate amount of work…
This is not the case with zynthian.
Ayway, currently zynthian security starts with the password. How many of you have changed the default password in your devices?
The current Debian version is Bookworm, the Debian 12 life cycle encompasses five years: the initial three years of full Debian support, until June 10th, 2026, and two years of Long Term Support (LTS), until June 30th, 2028.
