It’s a testing image, not production ready! It fixes a lot of things and it’s quite usable, although you will find issues, of course:
webconf terminal works again
webconf MIDI log works again
wifi is now configurable from the UI. Probably buggy as it’s very new.
it should auto-configure V3, V4 & V5 on first boot
hopefully, it should auto-configure bare-bones setups with HDMI+ RPi native sound
a lot of fixes everywhere
a lot of issues to fix yet
You probably need a 32GB SDcard. I will try to reduce the size until it fits in 16GB, but 64 bits binaries & libraries seems to take more disk space.
If you already have an older bookworm 64bits image, you could try to update and it should work. If you do so, please, change your zynthian-sys repository to “oram” branch.
Be warned that Oram 32 bits images (buster) are not supported anymore! Please, don’t report any issue from oram 32bits images. Everybody testing oram MUST use the bookworm 64 bits image.
You can report your issues with the 64 bits image in this thread or in the tracking system.
Speaking on behalf of the peanut gallery, I see very little point in getting it to fit in 16GB - I haven’t gotten any sd card less than 32GB in a long time. Any effort or time spent on shrinking it could be used to do something with better payoff. And we’ll probably keep encountering the problem anyway with future versions that support more functions and midi controllers etc.
I respectfully disagree with our wonderful friend @tunagenes! There are many users (me included) that have 16GB uSD cards in their devices (mine was in my V3) that we would like to retain. They may be long in the tooth (like some of their owners) but we don’t want there to be a barrier to upgrading with users having to buy new hardware and await delivery (time and cost which adds friction).
Well done to @jofemodo for his ardent effort in progressing this. The move to 64-bit Debian 12 (Bookworm) based system has substantial advantages that are too numerous to mention. (I am enjoying using Patchage without the need to restart it every few minutes.) Of course with such a substantial move of OS combined with the massive changes to the core Zynthian codebase - we will all be experiencing the joys of bug discovery, reporting and resolution. May it be cathartic for us all - food for our very souls!
Thanks @jofemodo! You are a wonderful man and I for one love you very much.
64-bit provides some improvement in resource handling which brings a bump in speed / amount of processing. It also avoids redundancy. We don’t want to be rushing to resolve all these issues at the last minute.
This is, of course, also important. We are not going to have 128bits CPUs in the near term, so after this move we will seat comfortably in the 64bit architecture for a long time, without limitations regarding RAM addressing and enjoying a little improvement in performance.
Developers, specially me, will be more relaxed and focused in what is really important:
Understood. I’ll just give the Oram images a try from time to see how things are progressing. Also, in the case of my Pi5 I also have an nvme drive and that caused some other issues. Good fun!
I continue to test Oram: For my snapshots I use Zynaddsubfx, Sfizz and the chain-audio player, no ZS3. Oram is much faster when loading these snapshots, I would estimate twice as fast.
Huge portions of zynthian’s internals have been refactored. Although GUI hasn’t changed a lot, internals are quite different now. Almost every part has been touched and performance improved when possible. And the best is yet to come in the next months …
I am planning to experiment with the RPI5, to see what it can handle ina an audio generation context.
While waiting for the prospective V5.x upgrade kit for RPI 5, I wonder if I could try a bare-bones installation, on the SBC with a Hat adapter, once Oram 64 is released as stable and providing it will support RPI 5. I could also consider the option of installing and assessing the current testing version, but I am not sure if it would make much sense to test the OS in development on an unofficial and self-assembled hardware setup.
Since I don’t like to buy equipment which later ends up being useless (dangling around the house just to remind me to find a way to sell it on the second-hand market), it would be helpful to know if I might arguably reuse an affordable Crucial 3rd gen NVME drive, once the Rpi 5 upgrade kit, or possibly even the ensuing V6, will have been made available by the Zynthian Labs.
Furthermore, I wonder if a general-purpose Presonus audio interface on USB may be configured to work with Oram 64 and Rpi 5, and, if not, whether a cheap HifiBerry DAC2 Pro connected through GPIO would do the trick.
Although we don’t have plans to actively support NVME drives, the RPi5’s PCIe connector will be accessible in the V5-Pi5 kit, so you would have the possibility to plug and configure your NVME unit.
Regarding how you integrate the controller board+drive inside the V5 case, i think you could find a good place for it. Double-side tape is your friend
Currently both options should work OK. We are having issues with audio input in some i2s cards (jackd can’t work in full duplex), but AFAIK, audio output works perfectly OK.
Hi- I am testing the newest oram image. Is anybody else having problems adding audio chains? I can’t seem to get more than the first four plugins to show up, and audio is not going in at all (audio out works). I am using a rpi 4 with a generic 7" touchscreen and Audio injector stereo sound card. Also, MOD-UI is not loading for me.
