This is to let know to the discourse’s good bunch of people that the DSP 56300 Emulation’s community has publicly released OsTIrus, a low-level emulation of the Access Virus TI digital synthesiser.
I have been using it for a while, as a beta tester, and I must say that it sounds absolutely spectacular. As with other DSP-level emulations of the same English developers, no hint whatsoever is and must be shared, as to how and where to source independently the hardware synthesiser’s proprietary firmware. In this case, the process is a bit more convoluted than usual, but techy guys with a smart head can solve the riddle!
Albeit I unfortunately lack the coding literacy for verifying the subject on my own, I gathered on the Internet that compiling LV2 plugins for aarch 64 (which is required for them to run headless in Zynthian) seems to pose a series of technical challenges. At the moment, only CLAP, VST2 and VST3 versions are available. I will try and pull a request on the Discord channel of the DSP emulation’s community, raising the topic of making their excellent plugins available for the Zynthian platform.
Of course, should we ever lay our greedy synthesiser enthusiasts’ hands on aarch 64 LV2 versions of Osirus (Virus B/C) and OsTIrus, it will be up to @jofemodo and @riban to find a legally safe way for including the DSP emulators in the LV2 repository, without the respective ROMs until the day Access will possibly give up repurposing their proprietary code (through licensing/reselling to third-party companies) and will set it free in the Open Source wilderness.
I investigated the subject of LV2 for aarch64 on the DSP56300 Discord, and they actually already have that OsTIrus plugin available, in the extended link with more builds located under the list of versions in the website.
By the way, this is true for Osirus (Virus B/C) as well.
Providing that Oram 64 will be capable of handling the appropriate number of MIPS with RPI 4 (and prospectively I hope RPI 5) - which might be ascertained running the provided Linux test console somehow on the Zynthian hardware - I think that the emulator plugins could be tentatively included in the LV2 repository of Oram, if they happen to work after appropriate tests (not sure anyway if they would expose parameters, due to the mentioned JUCE 7 issue in ZynthianOS).
Is it all it would take, or am I possibly missing something?
Zynthian runs on Raspberry Pi which is aarch64 based so requires aarch64 code. If a LV2 is provided with aarch64 compatible library then Zynthian can host it. But there may be integration issues like the lack of parameter control and there may be performance issues due to lack of resources (CPU, etc.). The GUI may require a particular toolkit. (Zynthian supports GTK3 & QT5.) Otherwise, it should work.
About the legality of including it, I guess the best way is to leave that to the Virus owners that might want to “clone+shrink” their TI into a Zynthian, since those have access to the OS files.
Still haven’t got the chance (=spare time) to try Oram on a fresh SD with V5, but I think that the standard directory, to be accessed remotely via SSH on an external PC connected via ethernet cable, should still be:
/usr/lib/lv2
Keep in mind that no further instructions, as to where and how to place the autonomously sourced firmware file, must be discussed anywhere - as per the DSP 56300 emulator rules - but it should be obvious.
Also, do not take for granted that Zynthian will recognize and be able to manage the osTIrus parameter set, within the specific Oram GUI, nor we should assume that the presets would be imported and work as expected. I believe that the lv2 plugins loaded with the Zynthian OS have been previously checked for functionality, and sometimes optimised in order to work inside this specific IT environment.
Hi Guys, is there any information about how to install and try third party LV2? I know that some problems can occur I just want to try it out, but no luck.
I have the deb package compiled for Linux aarch64, I can unpack it it does not contain lot of things. mainly the libOsTIrus.so. I tried create a directory ostirus.lv2 and put the so file in, but I am not sure if that is a correct aproach and I cannot find it anywhere in zynth UI. So… Any guidence would be appreciated.
If you have an arm64 deb package then you should be able to install it with dpkg -i filename.deb.
The .so file is the library that does the work but it also needs .ttl files which should also be in the deb package. Using the installer should put them in the right place, then you need to Search for Plugins in webconf.
That is what I did, I think it put them inside /usr/local/lib/lv2 but the ttl file is not the part of the package.
You mean Under the Plugin page?
Checked it again, there is only so file no ttl. Can ttl be created manualy? I know its a manifest file for the host to know what is dealing with, but could it be done just by providing basic info?
Preparing to unpack ostirus.deb …
Unpacking dsp56300emu-ostirus-lv2 (1.3.14) over (1.3.14) …
This is a poorly packaged deb. It installs the lib into the wrong directory and none of the required ttl files. Someone else mentioned this in their discourse. That person created the required ttl files from source. I recommend that you report this upstream.
Hi @culfytt, have you signed in for the DSP563 Community server (i.e. Discord Channel)?
Until now I haven’t been able to investigate this topic further, but soon will. It looks like the majority of Osirus/osTIrus users are Mac and PC-based, so the Linux and Aarch64 builds are partly inaccurate for the time being, requiring quite a bit of added work on components and configuration.
we found ourselves via google here, we never heard about Zynthian yet, an interesting project.
We just pushed a fix for the LV2 packaging to include the ttl files. If you build from source, you can specify the CMAKE_INSTALL_PREFIX so that the resulting .deb/.rpm will install to a folder of your liking.
However, there are other issues that would need to be solved:
The TI will not run on a Raspi 4 no matter what because the CPU and also the memory bandwitdh is way too slow. We do not have any experience with the Raspi 5 yet, but we have an Orange PI 5 and this one is very close to realtime. A V5 kit would be a nice toy to play around with and get it running.
The GUI is another topic. The Virus TI has 7000 parameters, over 300 per channel and multi and global parameters on top. I wonder how that should fit on that small screen with four knobs.
Instead of attempting to run the TI, I’d recommend to try to run Virus A/B/C first. The A is the one with the lowest CPU requirements because the single DSP was only about 72 MHz and also it has the least parameters.
I opened this thread because I am among the Zynthian users gently lobbying for the future inclusion of the DSP 56300 emulator, among the available synth engines.
I am also on your Discord, as a donator member and enthusiast user.
There have been standing issues with the code until now, while attempting to install the plugin in an aarch64 environment like that of the new operating system Oram (based on Debian Bookworm).
We hope that your intervention may help us to solve some compiling problems, as highlighted by @riban in a previous post.
We are also quite confident that the overall increase in performance of Rpi5 and 64 bit will be capable of handling both Osirus and OsTIrus, certainly the first. Benchmarks on Raspberry OS have showed this, but keep in mind that Zynthian employs a very fast and highly optimised OS layer, and that the coming V5.1 hardware revision will use the Rpi5 as core computer.
Thanks for considering Zynthian for your further development, and keep in touch!
All best regards
EDIT: As for the GUI, the current enclosure features twenty multicolour buttons and four multifunction encoders. Besides, native synthesiser interfaces can also be seen, for sound design purposes, on an external computer via VNC. As long as the emulators expose their parameters correctly, Zynthian should be able to recognise them and automatically order them in sequential pages, for its specific GUI operation model.
,
