Will the AI Bubble kill this? Large shift in hardware might be needed, for hobbyists at least

[jtode]

Here in Canada, a 16GB Rpi5 is $375 now. I 100% had plans to pick one of those up, and put it into whatever the next Zynthian model looks like, until this madness. I wanted the 16gb specifically so I could hold a lot of samples in memory.

But now, I could pick up a used mini office PC from any of a number of basement resellers in Winnipeg, with 16GB, an i5 or i7, an SSD, etc, for the same price, but actually less. Prices on those took a leap too, but not as rough as that taken by the corporate concern known as Raspberry Pi.

14 years ago I bought a little SBC that had composite output, could be used anywhere in the world that had a little bit of resources, was cheap as heck, and had this miraculous GPIO stuff, and that “small computer that interfaces with electronics at hobby level” caught the imagination of the world, as we all know, such that when supply chains became disrupted, the hobbyist users - the people this platform supposed was born to serve - became second class to the business people who had appropriated this hobby platform for their commercial projects.

And now it’s so much worse, because they have driven the prices of everything up, again, pushing the User to the back of the queue for their plagiarmism machines, which they seem to believe will become a public utility that we will all have meters on our house for. The correction for that delusion will be ugly.

But the thing on my mind right now is, for us hobbyists who like to build our own things, and all respect to all devs/engineers of this project, but is the Raspberry Pi platform, or even an SBC in the final analysis, the most economical/rational way to continue?

Because what I keep coming back to, is that the only feature we need and receive from RPi is the GPIO, and they are not even very good at that, in the finaly analysis, other than their stability in terms of drivers and such. Everything else, video connections, storage options, even software support for Zynthian’s use case - musicians - are underserved on ARM hardware.

At the same time, it has never been easier to DIY a custom midi controller using any of a large number of very cheap MCUs that are out there, most costing less than ten bucks. My first home-built Zynthian (a v4) did use a Pi, but all controls arrived through the USB port, via a Teensy. Worked a charm.

Reimplementing the V5 interface would be a fair bit more effort, but with the combination of a set of controls on USB and the recent moves towards being able to add the Zynthian UI to a normal Debian system, we could shed the Raspberry Pi ecosystem entirely, which I would argue, is well worth discussion, at the very least.

If this were to be seriously considered (or done as a fork), I would envision it having a reference motherboard/CPU, which could still be a highly compact system, such as a NUC or a Lenovo miniPC or some such, the main requirement being robust USB-C support.

If we had that, then the Zynthian’s display, as well, could be integrated into a single device, which could operate both wired, as USB-C handles displays just fine, and If the reference MCU is robust enough (recent ESP32s are quite impressive) it could work via Bluetooth or Wiffy, with the MCU feeding the UI to the screen and an onboard battery freeing the player up.

Those ESP32s of late, with their fast RISC-V CPUs, could even carry some onboard synths to make it a stripped-down portable unit on its own as well. I’ve always felt there should be a version with at least a small keyboard integrated too.

My enthusiasm for this project will never wane, but I think it’s worth examining the facts on the ground of late.

[wyleu]

The Company Kingston grew out of a similar RAM shortage in the past.

One of the handy things the market does is adjust to such situations as these.

You can’t get round the need for RAM for some applications, but open source also has a nice way of adapting round such issues.

It’s worth looking at the Pi Pico for a device with the carefree attitude of the early Pis’ if not quite the power we require for what we feel we deserve.

[riban]

I believe the Raspberry Pi Foundation is still committed to providing accessible computing and has done various things to cope with the current world problems that have affected cost of RAM, GPU and to a lesser extent, CPU. We may have to weather this storm.

Some advantages that zynthian leverages from RPi are:

• Consistently good support from the Raspberry Pi foundation.
• Consistent supply and design.
• ARM architecture giving good processor to heat ratio, allowing for a silent (fanless) design.
• Generally competitive price.

Each time we consider alternatives, these benefits outweigh everything. Choosing a different platform requires time, money and effort to investigate, prototype, validate and then you and not sure of longevity. We have seen our friends with similar products change platform, with lots of research and assurance from suppliers, to be very soon faves with broken promises and unsupported hardware.

Anyone can build a variation and do all the leg work but they will hit lots of snags and face criticism from users who have their own requirements. (We have faced all of this over the years and have this platform now the meets lots of users’ needs.

[jtode]

Leaving aside the USB-C monitor (and I mean, how long until the Pi replaces the much-despised MicroHDMI with lovely lovely USB-C? Maybe never?), what I propose here does not actually require leaving RPi, so anyone who wants to continue to build with that can do so. It would simply open up this platform to much easier hackability on the user end, stipulating the amd64 Debian support be firmed up into an easy package.

Like I said though, doing a midi controller with an MCU is not heavy stuff - it’s just pots and sliders and encoders patched into the Arduino ecosystem, which is easily as robust a platform as Raspberry Pi. We’re talking basic components, monitored and changed into midi messages at the pace of human music. I don’t see a lot of headaches, once the initial code is done, doing occasional updates to accomodate updates to the MCU hardware, as new generations emerge. They will always offer GPIO, I2c, SPI, etc, along with whatever goodies the manufacturers decide to integrate. updates would be mostly pin numbers.

In short, this is not a platform “shift” I’m proposing, nor a big risk - if anything, it’s increasing our safety. Nor am I really proposing we adopt anything in particular, aside from picking a reference bog-standard PC device. The point is only to offload the interface electronics from the Raspberry Pi GPIO, and onto an MCU, which could very easily be the Pico; I’m not here to bury the Pi or the foundation or take away from any of their achievements. Though I would again argue that the newer ESP32 devices make better choices, and again, are a highly variable but overall reliable platform with just as much staying power as Pi.

Long term, I would hope that we have support for RISC-V architecture, but it’s still early days there.

edit: here is the repo with the Teensy 3.2-based V4 controls that I implemented for my first Zynthian. As I said, worked a charm, other than, I could never figure out how to make the cheap encoders I used 100% proper - if you spin in one direction, and then reverse direction, the first notch in the reverse direction will not work, it doesn’t start actually affecting the UI until the second. I put this down to my janky beginner-level code. Also, in the end it’s not a midi controller, it’s sending standard keyboard letters to the CUIA interface.

But along with an HDMI with USB touchscreen, it is a PoC of what I’m proposing, only as I said, I would make it better by using a machine with USB-C and integrated monitor, and you might have figured out I’m kinda now planning to do this lol, and like I said, the beefy RISC-Vs running whatever synths they can compile and handle, maybe.

GitHub - jpaskaruk/ZynTeensy: A Teensy-based midi controller that implements the...

edit 2: I agree also, that RPi has done their best to not leave budget-deprived users completely in the dust - I genuinely doubt they intended to release a 1GB Pi5, but that definitely became a wise choice this year, and there are still lots of high-performance use cases for it - I think that could even run Pianoteq, for instance, which is the only reason I need a Pi5 Zynthian at all.

[Aethermind]

My feeling on the subject, in the current predicament (with the energy shock wave likely to worsen the silicon shortage, and impact prices in the coming months), is that the only standing limitation of the Raspberry platform for the Zynthian project is computing power, with a manageable heat dissipation performance. For the rest, I think that the Raspi platform has largely proven to be reliable, functional, retro-compatible, flexible for embedded systems and DIY concepts, affordable and caring enough for the finances of the entry-level user.

This said, there’s no denying that Zynthian - as a multifunctional and configurable ecosystem by design - is rapidly growing into a complex music production station, with an ample gamut of possibilities and applications, which require and will require stronger CPU and RAM provisions. The recent inclusion of powerful synths/romplers emulators and advanced FX processors has highlighted that the computational ceiling can be easily hit with just a few chains, even on a Pi5 16 Gb, when working within a multichannel/multitimbral context. No matter the careful consideration in building a snapshot with an eye on system resources, there are objectively various operational scenarios where more than one Zynth is required, and this kind of implicit system scalability with relatively affordable costs is/will be probably the answer, for quite a while.

I too believe that the widely despised Micro-HDMI is a backwards-looking technical choice, dictated by dimensional and cost constraints, which imho will disappear with the next generation of the Raspberry SBC.

By the way, there definitely seem to be Internet rumours, concerning a possible Q4 2026 or Q1 2027 release window of the Pi6, with an expected substantial jump in CPU (Snapdragon) power, memory up to 32 GB, better physical connections and improved WiFi performance. Of course, all of this sounds obvious and, again of course, no official statements of sort from the Raspi foundation.

[tunagenes]

I searched on raspberry pi snapdragon and the first 2 hits were negative on the idea, although both were quite old:

[Aethermind]

Yes @tunagenes, as always in such cases there tends to be wild speculation around, about possible or expected hardware specs, most of which is by definition… purely fancyful chatting of techno geeks like us!

Cheers

[riban]

I too build my first zynthian with a MCU providing hardware interfacing (encoders, buttons, etc.) and the codebase for this (STM32 based) implementation is actually part of the zynthian codebase but has languished unloved for many years so is probably suboptimal or not working. We have discussed the idea of offloading control to a separate MCU several times. The main resistance was the need for some mechanism to update its firmware when bugs or features need addressing. There is a way to do this now which might allow such implementation in the future. Another concern is that it is another piece of hardware for DIY users to integrate. I still like the idea of putting all the hardware UI dynamics into a separate MCU which sends events like SHORT PRESS to the RPi rather than the RPi code having to keep track of press, release, etc. We will undoubtedly revisit this topic. It could release some valuable processor resource back to the important business of making music.

[jtode]

Meant to get back to this…

One of the handy things the market does is adjust to such situations as these.

A bold new company juicing up a sector by sending a lot of orders to every manufacturer, boosting the whole economy’s bottom line while introducing the need to hire a few more people, that’s the sort of thing you are talking about when you say markets adjust.

What’s happening right now is something differentt. Very different, with different knock-on effects. If someone were to start a new RAM company (though I’d be interested to hear which new fabs they’re using, cause the point here was to get it all, not just juice the industry; jamming up the whole works to prevent anyone else getting any was the main point),

So far the opposite has happened, whatever the case: one of the biggest consumer ram brands has shut down. If someone does start a new RAM company, one or another slop company would immediately either buy up their entire output or hostile takeover them. I have money to wager if you wanna.

We’re gonna have a new Bastille day, before this ends.

[wyleu]

Leaving aside the USB-C monitor (and I mean, how long until the Pi replaces the much-despised MicroHDMI with lovely lovely USB-C? Maybe never?)

As someone who possesses far too many HDMI leads and equipped Monitors and a large thriving USB A eco system, type C was a mixed blessing. I like to reuse and downsize kit. The Monitor that the thoughtful Bank I worked provided eight or so years ago allow me to write patchy code, may have only had one HDMI port on it ( allegedly to reduce the chance of people nicking them or more likely an exercise in how cheap can we go when ordering thousands), but it’’a still here sitting on the desk next to a Pi 5, displaying this conversation. The two micro HDMI connector is a thing of devil exceeded only in my loathing for barrel connectors, but there is an hdmi monitor on both of them. So from the perspective of the Pi infrastructure these hardware standards are baked into an evolving subsystem possessed by many.

There is a certain reuse and repurpose element to dmi, but I suspect as the modern generation of bank monitors eeek their way out to the Pi users things will be ready to move on to Type C.

Anyone want a VGA monitor ( funnily enough you can easily build a driver for those on a pico) ?

The CM5 on mother boards with appropriate connectors might be a suitable way forward.

Again selfishly from a hobbyist perspective, the loss of a basic 5V infrastructure supported by ‘modifying’ USB leads I view type C with a slightly weary, hear we go again. The type C power provision and negotiation mechanisms is obviously the way to go, and anything than both power and communicate within one cable is exceptional.

Once you get out into the wild then connector technology takes on a different perspective.

Drummers and the like.

Rugged USB-C - Amphenol PCD

So the core computing element would perhaps be cm5 based and then the issue of amount of RAM and connector technology comes down to a PCB layout that accommodates the CM5 connectors.

I don’t so much want to do more powerful things with the zynthian kit, I want to do the same things with smaller, lighter more economical kit. ( Think batteries ).
We have probably had the computer reserve to do a decent sooperlooper implementation for some time, but the progress is a little deadlocked on how we can implement this sort of device in a variaties of control environments. The joy is that the system that has been constructed has so many methods of interaction that we are almost spoiled for choice. The V5 zynth, to my mind, bridges this gap perfectly, But as the zynth has changed from a minimalist implementation of hdmi monitor 4 encoders and four switches to a push button interface, I as a hobbyist Zynth builder are still scratching my head about how I track this on a few bits of stripboard, some jury rigged WS2813 strip LED’s, and my solution has been note involve from v4 zynths, bed down and wait for RAM to assert it’s usefulness in the world and the money motivated individuals can stop their games, beit fiscal or military, and then I will start to look anew at the Pi5’s. In the meantime I’m very busy getting my head around the Pi Pico as a control device.

When one can fly to the moon on less memory than ….. Perhaps we have a little to learn from working withing imposed limits.

If you have been thank you.

This was bought to you via the Pi Pico Party.
Do it in Risc V as well!

[Baggypants]

On the topic of AI but unrelated to hardware is the idea that AI is undermining the concept of any sort of software licencing.

Chardet dispute shows how AI will kill software licensing

[jtode]

I deliberately chopped down a giant reply to wyleu last night because I didn’t want to come off like I’m here to grind an axe, but I will say for just a moment that the AI grift is the worst yet, on so many levels, but it is precisely that - the “worst yet” version of a thing they’ve been doing all along, while people have continued to trust that they were working on delivering the promises of the 90s: a hyperconnected world where all communications and transactions and so forth would be effortless, smooth, etc. In fact, they have simply setup Troll Tax stations at every place they are able to in our lives.

A shortened version of the rant is, look into Uber’s business operation, history and tactics. Look at their product, how very easy it is to implement, and especially focus on how they came to dominate this “sector",” noting that the one focus they had was, indeed, to dominate the sector through hardcore business methods, not superior technology. The “Silicon Valley Hippies” of the <=8-bit days are all dead and their children are, to a man, Caligulas. AI is their grandest slaughter of the innocents yet.

I am like a sympathetic string on a hardanger fiddle when wyleu talks about doing more with less. I remember how the games on the C64 kept getting better and better over the years, while the machine did not change (to the point that they just release Super Mario Bros a few years back). I remember how Microsoft, over and over, demanded unreal specs on their new Windows versions, while doing absolutely nothing new for the user, but chugging away at Who Knows What under the hood.

And that’s basically why I think the project should decouple itself from a specific compute platform, and formally support amd64; the soul of a Zynthian is in the UI software, but the body is not in the CPU - the body is in the knobs and buttons and touchscreen, all of which can reach the soul via a $10 MCU rather than the not-that-great GPIO of what has become an expensive and highly proprietary closed source platform. You wanna talk license problems, by the way… :>

[jtode]

Oh also, short one, re silent/fanless operation:

As a bedroom hobbyist, and maybe in a very limited studio space, a silent machine is advantageous. Any good studio space already has the environment setup to isolate noisy gear as necessary.

As a gigging musician, a small fan cooling the gear is not remotely a bad thing, and the noise is a non-factor when you’re on a stage with amplification. It’s “nice to have” if you can manage it, but I would question using my V5 if I was playing a hot outdoor gig where my gear might be in the sun. Even some summertime bar shows I’ve played were sweltering, and in those environments I would much rather know that my stuff is actively being cooled.

[wyleu]

@jtode

I didn’t want to come off like I’m here to grind an axe

No problem.

The width of opinion and the interactions between them is an important component of moving forward.
Good ideas thrive and people amalgamate those into their own visions.
The Better, mostly drives out the good, generally against the short term fiscal gains, and to be discussing it is simply a indicator of the successful nature of what we are involved.

[wyleu]

@jtode

I’ve played were sweltering, and in those environments I would much rather know that my stuff is actively being cooled.

There is a zynfan mechanism in the code base somewhere which PWM modulates the fan speed and is whisper quiet when not much is going on and is certainly an acceptable ( imho) when you are going for it as that, presumably when your device is making a bit of noise that in the fashion of Mp3 shadows the fan noise.

It keeps most of my son et luminaire Pi4’s acceptable in environments that wouldn’t benefit from fan noise in the quiet bits. . .

Yep there it is…

etc/systemd/zynthian-pwm-fan.service

[Baggypants]

@jtode

And that’s basically why I think the project should decouple itself from a specific compute platform, and formally support amd64;

I started using zynthian on a netbook, and now I have a touchscreen laptop I was thinking of revisiting it. However a more generic compute platform would be expected to run a wider range of software, and users would probably feel Zynthian shouldn’t be running as root.

[jtode]

I’m a Sysadmin, have managed large Unix-based networks and render farms and such. I know, viscerally, the pain of migrating a process run conveniently as root down to a user account, particularly for the uninitiated. I am certain that I can make a non-root user work, if that becomes an issue. If it’s desirable, I could get to work on that right now. Indeed, if we haven’t adopted Pipewire yet, Debian runs that in userspace, there will be pain trying to run as root. Pain either way. Hit me master.

I could see there being problems getting Debian to pull the code for sure. I’d personally be perfectly happy being able to pull the repo and build myself, but I’m, you know, a freak.

edit: example of my freakitude. I have acquired a Digi002 for $50 and a 1394 card from Ali and I am today researching whether there is a Jack app that will allow me to use it as an ersatz digital mixer, or if I will need to code my own using the Python Jack module. Or maybe do it all in Puredata, not sure. This is strictly to wrangle my live rig, which still uses discrete pedals for a couple things. If I can get it working I’ll find a few more $50 Digis and won’t have to worry about that for the rest of my life.

Part of my pain in this is that I am uncertain about Pipewire in combination with FFADO, though having done some reading I am told that Pipewire still rides on top of the fundamental ALSA system, so I expect I will be able to use pipewire-jack and not have to start immediately locking myself into antiques across the board to make this work.

But main point being, wrestling with Linux is what I do for fun and I can get that done, if it’s proven a challenge.

[jofemodo]

Zynthian-ui can run in a desktop computer as a users process. I do It every day. No problem with this.
The reason to run as root in RBPi is simplifying things. We could change, but IMHO, it won’t bring any real benefit in a embeded device and would make system maintanance more complex. More effort on system stuff, less effort in core development.
Security is not a Big concern for us. Nobody has reported attacks or intrusions until now.
Of course, if this changes, we would move to a more strict config.

Regards

[jtode]

Security hardening is never a bad idea. That’s all I gotta say about that.

[jtode]

@riban

another piece of hardware for DIY users to integrate.

This is less of a problem than you might think. My electronics area is lousy with arduinos, teensys, etc, but not a single MCP23017 to be found. If the hardware was routed through an arduino-type device, DIY construction would be far more likely to happen on a whim, rather than by ordering a multiplexer that maybe they ain’t got.

Arduino is kind of a great leveller here - many people have them already, and many devices speak arduino. I believe this would be a far easier pathway, because most of us would be able to make a device already on hand work.

But it’s not really a new piece for the DIY builder - the MCP device is already that, and likely a more difficult one. But just about any arduino could do the same job, maybe not the 8mhz Uno, certainly not if you wanted to add a velocity-sensitive keyboard or whatever, but anything with a decent clock speed.