I successfully built an LV2 version of Osirus and was able to load it on Zynthian but only in the Mod-UI plugin host. I assume that this is the wrong approach, it doesn’t show up in the plugin list that is on screen.
1 Like
Hi @dsp56300!
If a LV2 is installed on zynthian (in a sensible place, i.e. somewhere that lv2ls will find it) then it will be detected by zynthian after running “Search for Engines” in webconf SOFTWARE->Engines and enabling in webconf. (You can now also enable/disable engines from the zynthian UI by bold pressing on an engine in the engine selection list.)
1 Like
This is great news, @dsp56300 !
With this we can fully integrate the osyrus in zynthian-ui.
Please, could you share the LV2 bundle for testing?
BTW, are you using juce framework?
Regards,
1 Like
yes, we use the Juce framework indeed. I am hoping that doesn’t cause too much trouble.
Looking good so far, but it seems to start hanging after some minutes of idling. Does Zynthian do any plugin freeze when it is not in use? What exactly is it doing?
Osirus playing the “Test MIDI” file:
CPU load while doing so:
Looks promising, but still work left to be done.
1 Like
I have it installed with an Access Virus C ROM. It has no presets (I guess not surprisingly) and the default produces no sound. None of the controls present to zynthian but that is likely to be jalv’s inability to present parameter to zynthian. (We use control ports.) Selecting a preset from the native GUI still presents no sound. I may take another look tomorrow.
[Edit] It has started to work. I am not sure what has changed. I note that the title of this thread relates to Acces Virus TI but we seem to have drifted to Access Virus C.
1 Like
Does this require a different emulator? It did not recognise the ROM I have for TI.
A, B & C use the Osirus plugin.
TI use the OsTIrus plugin.
1 Like
Yes it is a different emulator, OsTIrus is for the TI family while Osirus is for the A/B/C
https://futurenoize.com/dsp56300/builds/ostirus/beta/DSP56300Emu-1.3.20-Linux_aarch64-OsTIrus-LV2.zip
I see it starts to xrun and lock up zynthian. It looks like a memory leak or other fault in the plugin.
not really Deadlock when attempting to log to stdout
1 Like
I have downloaded the latest Osirus and OsTIrus beta releases, which I pleasantly saw were not DEB packages, but LV2 sub-folders with all the relevant files, just ready to be copied into the Z (thanks @dsp56300).
That I did, using an SFTP client, and placing the two plugjn folders (with the ROMs added inside) in the correct listed position of the Oram/Bookworm directory tree, that is:
usr/local/lib/lv2
I entered Webconf, rebooted the Zynth a couple of times and after was glad to see that not only the two new engines appeared in Webconf > Software > Engines, but they were also available for new Instrument Chains, in Main > Add Instrument Chain > Synth.
So far so good, but no presets and no sound with incoming Midi data.
Thus, I asserted VNC in webconf > UI Options, rebooted and went to see the GUIs of both Osirus and OsTirus, which the VNC server showed perfectly on the connected computer in UI Options > VNC Engines.
Presets were obviously there: I tried to select some patches to no avail, still no sound from the Zynthian, neither Osirus nor OsTIrus.
Then, magically and out of the blue, both plugins started to work, with presets selectable from VNC! 
Until now, I have observed that my custom Pi5 with Oram and nvme drive, at medium overclock, manages reasonably well Osirus and a few other instrument chains, with a buffer of 256 samples. The same setup and config handles nicely most OsTIrus patches (with sublime aural results, what a software synth! 
) if its only synth chain is loaded in the snapshot, while selecting certain cross-modulated fx-heavy patches, or adding more instrument chains, can lead to dropouts or clogging the audio system completely.
I wonder if:
Changing the overclock to maximum (temp is already about 60° with OsTIrus running) or resetting to no overclock might improve performance;
VNC imposes such a significant computational overhead that impacts performance. In this case, having the presets exposed to the Z without VNC and native GUI could increase audio stability of the emulators (with the standing problem of the inherent complexity of mastering their synthesis structure, without their specific GUI).
1 Like
Mine is set to maximum at the moment, mainly to speed up compilation. While OsTIrus is running its at 51.6ºC
Yes, obviously having parameters exposed to the screen will help, also to have the presets available. Its just that we are not yet aware how this is actually done.
That the engine has xruns and eventually stops completely is due to the emulator logging to stdout, see Deadlock when attempting to log to stdout
Fix will be coming soon. Also, a cmake preset especially for Z is being worked on so that everyone can just clone the repository and build/install directly on the Z
This will be as simple as
cmake --preset zynthian
cmake --build --preset zynthian --target install
Once thats done you do a rescan and are good to go.
2 Likes
This ball is our roof, @dsp56300! You don’t have to do nothing. We must implement a LV2 feature we don’t support currently.
FYI, “traditional” LV2 plugins expose its parameters as “control ports”. This has pros and cons.
There is an alternate way of exposing parameters in LV2 as “dynamic properties” that was specified more recently and hadn’t be used too much until Juce decided to adopt it to generate LV2s. From this “event”, the number of plugins using the new way is growing fast and we MUST adapt zynthian code ASAP. We have been quite busy with the Oram release, but now it’s done and this is probably our first priority.
Regards,
4 Likes
WIll this procedure build the preset library in LV2 format (TTLs)?
Exporting the library by hand using the native GUI could be painful and really hard to maintain.
I think Juce already have tools for doing so automatically. SurgeXT is doing it, so perhaps you could take a look to how they do.
Thanks!
1 Like
No, this is not possible because the available presets depend on the used firmware so this is dynamic. Are presets in a separate ttl file? If that was the case we can maybe create ttl files that match specific roms and the user has to copy them to a specific location?
What is the content, can this be sysex? Or what is technically done if a user selects a preset?
That’s good news 
Probably requires us to do better parameter grouping but we can do that of course.
Zynthian UI can’t access plugin’s internal presets. This is something each plugin/framework manage on its own way. We stick to LV2 specs and use LV2 presets, that is the standard mechanism for LV2 plugins. It’s the only way that you can choose/change presets from the zynthian-ui (without using the native GUI and VNC), so it’s a must for good zynthian integration. Each plugin must export its preset libraries in LV2 format.
LV2 presets can be organized in LV2 banks, so the mapping is quite good. Also, you could add tags to presets/banks, so they can be filtered from the UI depending of the firmware ROM being used. It’s not implemented currently, but it wouldn’t be difficult.
Regarding how presets/banks are stored in TTLs files, LV2 is very flexible and doesn’t impose a way. We like using a bundle-dir per bank, and inside each bank dir, presets are saved as separated TTL files. I have included some example zipped so you can take a look:
Odin2_Keys.lv2.zip (288.0 KB)
Odin2_Leads.lv2.zip (337.5 KB)
Odin2_Pads.lv2.zip (490.3 KB)
These are 3 banks for the Odin2 plugin 
Regards,
1 Like