As the title says… I really don’t know if it’s practically achievable.
I built a custom Samplerbox some years ago. It’s hooked up to a midi drumpad for live usage. After crashing some SD-cards in the process of building it I ended up making the SD-card read-only to prevent damaging it again. It runs from an overlay file-system as explained in this video. It’s been running for years now, always unplugging the Raspberry Pi without ever powering down. It still runs from the original SD-card. All samples and configuration files are stored on a thumb-drive. As you don’t save data to it playing live, there’s very little risk of damaging that one as well.
First suggestion: I know a Zynthian box is way more complex, but could it run from a locked SD-card?
Second suggestion: latency is always an issue. That’s why I made my Samplerbox run headless. This vastly decreased latency. Could this work as an optional feature for Zynthian? Thinking out loud: the system could check wether the ‘Back’ button is held down during boot-up. If so, the system doesn’t start X. Long-pressing ‘Select’ would have X fire up eventually or shutdown the system, whatever’s easiest to achieve.
Of course you can run zynthian “headless”, and some people is using it like that. Anyway, this is not going to have ANY impact on latency. Latency depends, mostly, of
Hardware => Buffers, chips, buses, clocks, etc.
Software => Jackd configuration
Latency on jack is deterministic. You tell jackd what latency you want and it will do its best to honour the latency you configured. When audio can’t be processed with the requested latency, you get XRuns, that normally means there is too much audio work to do.
As jackd runs with RT priority, the UI doesn’t affect audio processing, so you are not going to get a better latency for not having the UI.
This is theory, of course. The real world is more complex and ugly, and currently we have some random “XRuns” (mostly not audible ones) and we think this is caused for some obscure task-switching event inside the GUI. We are trying to solve it ASAP …
You could try, but IMHO, you will be wasting your time. Current zynthian images are quite safe and restrict writing ops to the minimum. I run my zynthians for weeks, months or years and never had a SD corrupted from 4 or 5 years ago, when i was starting the project.
Also, if you can’t write the SD, zynthian is going to be a lot less comfortable to use:
No config saving
No snapshot saving
No updates
Etc.
If you want to run zynthian safely, simply don’t use the recording functions (specially audio record) without plugging a pendrive.
All the rest is safe enough and you shouldn’t have problems. Of course, having a duplicate of your favorite and super-tuned zynthian image is a good idea too
I’ve been running headless for quite a while now, and without the overlayFS work that I did. I found most of my issues were due to bad power. I am a slight bit paranoid, and I had 2 identical setups in case one died, and a spare SD card ready to go. Never had to use any of the backups, but you have to have bombproof gear if you are going to use it on the road…
Unfortunately the band did not last as long as the Zynth.
I’m afraid I’ll be the proud owner of two zynthians as soon as it’s integrated in the band’s sound. Too bad Mod GUI is far from stable. Having those issues ironed out would increase its use (and me depending on Zynthian) even more.
