Thanks for the regular updates, on your successful effort to run Carla and the Aarch64 Osirus VST3 plugin on Zynthian.
I must admit that by now I am a bit lost, on the actual state of things regarding the latest candidate workflow, for the installation of the whole package in Oram with Pi5.
I wish I had your uncommon fluency in Linux command line operations, that allows you to be fully conversant when you discuss IT topics with our skilled in-house specialists @jofemodo and @riban.
Thus, it would be useful for the community if you summarised what is your current model for getting Osirus aboard the Z, between CLI installation lines and usage of the VNC server to manage and see Carla and Osirus.
@gadg3ts appreciating your efforts, but all this manual work with VNC and stuff should ideally not be required if the whole thing is done properly. Sorry for asking absolute beginner questions, but what prevented you from trying the approach that is described in the Z wiki, wrapping the LV2 with some python scripts to have it integrated in the default UI?
We bought two V5.1 kits and we want to support it properly if it doesnât take ages to do so. Both have been assembled, one of them has the project cloned and currently compiling it.
But we have to read up on it to know what to do next.
While @gadg3ts is doing a great IT job, in refining and sharing his way to embed Osirus and the DSP 56300 emulator in Z, it would certainly be amazing to have the LV2 plugin compiled at the source, by the emulatorâs devs themselves.
I and others in this forum do think that Oram with Pi5 seems absolutely adequate, for running natively the DSP 56300 plugins, making of the Zynthian their potential portable host.
We will eagerly await for any possible positive development in your department!
I tested some first command line builds yesterday and Osirus did 250-320 mips for various presets, OsTIrus had more than 200 for individual presets and around 150 average while running the demo.
All numbers with âMediumâ overclocking setting. It is definitely possible to run them
Hello!
The short answer to that would be that I havenât read the wiki yet⌠(which I really should soon).
And yes, I agree it shouldnât require all this hacking about.
I think the current issue in integrating the plugins natively is that the .deb packages only include the .so file, whereas they really need the .ttl manifests to be available to be properly recognised by the system(?).
I found on the discord an arm64 build of the OsTIrus with those files, but not for the Osiris.
These are the sort of problems that really are worth resolving.
Thereâs nothing like the successful outcomes of people actually trying to use stuffâŚ
Assembling them was easy, quality of the whole thing is excellent. Good job guys.
But we had issues with the Pi 5 (we bought kits with the Pi included). While one of them showed some linux boot messages briefly at initial boot attempt, eventually both failed to boot with LED pattern 4 long and 5 short => âfatal firmware errorâ. We had to flash a new bootloader to the Pis to âunbrickâ them, once that was done and we created new SD cards the machines started to work.
Also testing here! Super nice sound!! But unstable yet. Probably the âstdoutâ issue reported by @dsp56300. The curious think is that it totally collapse the entire stack of plugins and it should not, as they run in separated jalv hosts. It seems to break jackd.
Here comes my noize tribute. Just jamming with the presets until it crashes:
Huge thanks to Osyrus developers!! This is going to be a big match!!
Yes it gives some great sounds. Maybe @dsp56300âs new (in progress) version without stdout logging will make it sufficiently stable. We must remember though that this will not be a simple engine for all users. It will require manual user intervention to source their own ROM and confirm their compliance with relevant licensing. This is extra to the standard zynthian open source software. It may be advantageous to implmenet a mechanism for uploading a ROM (that the user has manually sourced) from a userâs computer, e.g. via webconf. It may also be advantageous to expose a mechanism to validate a userâs acceptance of the licensing or terms of use.
Yes @riban, as of now, the road from enabling DSP56300 emulators in Webconf to actually be able to play them is not (yet) straightforward, and requires a bit of knowledge of Oramâs data structure and the softwareâs disclaimer/licensing policy. However, I think that a Webconf-based ROM upload service should be easy to implement, and with that - when @dsp56300 and @jofemodo will have come up with a way to expose engines parameters internally - the non audio-dropout versions of Osirus and Ostirus would be fully integrated in the Zynth.
Just as a cursory confirmation of previous reports from other users:
I have left open and idle a snapshot with a single Osirus chain, on Oram Pi5 (medium overclock), without incoming Midi data and thus related calls for CPU activity. After some time, the audio system went in a crashed state by itself, arguably for the stdout highlighted issue, and Zynthian showed the alternate warning triangle/red heart sign.
