I’m new to Patchbox (and happy to help if my time permits as I’m an experienced Linux dev, though mostly a kernel person so far).
First, do you plan to respin the image based on Debian Bullseyes ? The current one barfs at apt-get update due to the change to oldstable and is … old
Then, would it make sense to have a 64-bit spin ? Maybe nor pre-built if it’s too much of a testing burden but maybe using then gen scripts as an option (or is there one I missed already ?). It should perform better on pi3 and 4…
Finally, those newer PIs support NEON vector instructions. Wouldn’t these significantly improve performance of the audio processing plugins if exploited properly ? Are you aware of any work in that area ? (Or maybe newer gcc auto vectorization is already enough to get some benefits ?)
I feel like Pi3/4 are under-utilized when it comes to processing… but it’s just a gut feeling at this point…
We use the Debian release that Raspberry Pi Foundation uses. It’s been a while since last image update, but as far as I can see, it’s still on ‘buster’.
Indeed, the biggest reason to support the same stuff as Raspberry Pi Foundation is because of the limited time we have for all our development initiatives. This way, the amount of testing, debugging and making sure everything works just right is minimized.
The community is free to try things out though - all the necessary stuff is open source anyway. Let us know if you have any particular questions that we could help out with.
Thanks. Yes, I noticed indeed, the RPi foundation hasn’t updated yet … it’s a bit unfortunate as debian “stable” tends to already be rather … old … to begin with
I’ll wait and see for now, but if time permit I’ll poke around at making your scripts able to generate a 64-bit image (if nobody beats me to it). I don’t have great hopes for auto-vectorization with gcc 8, but once Bullseyes is out, gcc 10 should be an improvement.
I’m interested to see what kind of performance improvements we can get out of it.
BTW. One drawback of the split of modep into individual debian packages it that it makes it a bit harder to rebuild the whole lot with tweaked compiler settings. I don’t know much about debian packaging (I know more about rpm though I’m a kernel person at heart), but I’ll try to fiddle and see what comes out of it.
Talking of updates… I also noticed MODEP is a bit behind on Mod versions, as a result depends on an older lilv. Do you plan to update it in the near future ? (Or would take pull requests to do so ?) I don’t necessarily have the time right now, but it’s going to be end of year holiday soon enough …
Sure, if you or someone can take on updating it, we’ll accept pull requests.
The whole lot itself actually are spread across quite different projects anyway though (mod-ui, mod-host being main ones MOD specific, the rest are open source LV2 plugins with MOD guis), so it makes little difference anyway, as each project would still have to be compiled individually, except building as debs reuses Debian’s package manager for taking care of install and uninstall tasks.
For testing purposes though, you may build stuff locally and overwrite the installed files with your own binaries, no need to know much about Debian.
I would be thrilled if someone with more knowledge goes ahead and tries to create an image with 64bit/rolling stuff going . I would test it out, since I did not have the courage to continue trying and ended just on raspberry OS
Similarly I am wondering about a Patchbox OS update or what the community could do to help to get a new baseline. If RPI Foundation is https://www.raspberrypi.com/software/operating-systems/, that is now is up to Bullseye as of 10/30/21.
I would love a new patchbox image, as mentioned in this thread, it’s kinda broken tbh.
I used to admire how easy the Blokas team made this project for beginners ( like me ), now it turns out you’re supposed to have at least some advanced knowledge if you want to get a clean build.
Ended up in a loop because the initial setup wizard couldn’t fetch all the packages, couldn’t properly download them later without cleaning up some stuff.
Some implementations seem like a no-brainer, like the Orac controller ( web / pd patch ), but have never been added in the Orac module, would love some additional modules and button scripts, maybe have a Eyesy or ETC module, why not a headless Norns module …
I get that the team is probably busy working on newer projects, but this is honestly very confusing for most of the end users, the documentation that’s on the website might need a little revision too.
Yes, there’s a lot to update for the image and Linux is known to slowly break backwards compatibility as time goes on. The problem is that it takes quite a lot of effort and time to get everything just right for all the Raspberry Pi versions, and that is multiplied if supporting more than one configuration like 64 bit builds.
At this time we can’t work on producing a new image, eventually we’ll get around to it, but if there’s anyone in the community knowledgeable in Debian Linux would like to step up, let us know.
Just an FYI, I’ve started down this route. I recently refreshed my RPi4 with the official 64-bit Bullseye distro from the RPF. I got as far as getting it to run off the USB M.2 drive I have attached and added the Blokas repositories. I’m still thinking about how much I want to bite-off. I’d love to follow the steps of the folks that built the latest MOD version, but I’m also thinking of trying to rebuild MODEP from the Blokas repositories, or keeping it as simple as possible (too late, I know) and just install MODEP binaries.
I started going down the “While I’m at it, I might as well” rabbit-hole. I started with “Well, the latest Bullseye and gcc have better support for overclocking and SIMD Vectorization with the Pi4 hardware, so I might as well build what I can from source” and and I’ve wound-up working on a “Only What I Need” Gentoo build, that I will eventually compile the latest MOD Devices code.
The Gentoo bootstrap on the Pi4 has been a bit of a soup sandwich.
Wow, that sounds like quite the adventure! How far along are you with the gentoo build and do you care to share stuff like kernel .conf and the necessary patches? and make.conf, etc?
I like the idea of a minimal, optimized system for my headless supercollider machine, so please keep us up to date!
It has definitely been an adventure. I will definitely share what I can. Unfortunately, my note-taking started dropping off in the middle.
I would have preferred Arch over Gentoo, but based on initial searching, it looked like Gentoo for the RPi4 in 64-bit mode was better supported than Arch. After I get this running, I may try setting-up Arch on a second RPi4, to compare the experiences.
Let us know if you have any particular questions that we could help out with.